cancel
Showing results for 
Search instead for 
Did you mean: 

Recipe exports and source control

jessica-lie
Workato employee
Workato employee

[Nov 21, 2020] Mike Power (CRM Enterprise Architect at American University) posted:

I’m wondering if anyone uses the Recipe export functionality to check-in your recipe to source control such as Git.  I’m curious what your experience has been like and if you’d recommend that be a part of the Recipe lifecycle, or if you use a different approach.

3 REPLIES 3

jessica-lie
Workato employee
Workato employee

[Nov 21, 2020] Karl Nicholson (CIO from Synaptek) replied:

It would be really great if we could directly integrate our Workato recipe folders to git repos.

jessica-lie
Workato employee
Workato employee

[Nov 21, 2020] Tiago Esperanca (Solution Architect EMEA at Workato) replied:

We do have some customers doing exactly that, making recipe export / import part of their Continuous Development pipeline and that includes storing Recipe Metadata on GitHub or similar.

Out of curiosity, in one of the most recent examples they uses Workato API (https://docs.workato.com/workato-api/recipe-lifecycle-management.html) to automate the process and ended up storing on their Version Control System both the exploded zip file with all the JSON (so it's easy to review differences between previous versions there) and also the zip file itself, so it could be easily imported without having to rebuild it from the VCS.

jessica-lie
Workato employee
Workato employee

[Nov 24, 2020] Mike Flynn (Principal Software Engineer at Rapid7) replied:

We use the export functionality to store all recipe changes in Git.  We previously had a jenkins workflow to collect changes and create a deployment package for going to production based on branches, but this was a couple years ago and we stopped using it once our environments got a little more complicated.


We still use GitHub and the PR process for managing change in our environments. 


We do this for 2 reasons:

1. it is an important part of our process (communicating change, approving PRs, and visibility about when something is going to production).  This is a requirement for all software developed internally at Rapid7.2. store a copy of recipes that no longer exist in production for historical purposes (for the recent product hour  I resurrected recipes that were 2 years old to demo in the product hour) 

If you store recipes that no longer exist in production, make sure to save the entire manifest including a copy of all dependencies (including look up tables and utility callable recipes).


I would love to go back to a more "automated" deployment process, but there are a few instances where we have to manually adjust recipes once they are moved to production (like when NetSuite sandboxes have not been refreshed in a while and new fields have different internal IDs).