zapier convert for a cli version (or zapier version switch x.x.x)

[Quest Henkart]

Current Behavior

zapier cli seems to be targeted for development and not for deployment,
I cannot copy, install, or "switch" versions if the version is already a cli version

zapier convert only works on non cli versions

Desired Behavior

zapier convert to work on cli and non cli versions (or have another more appropriate name for switching to a cli version like zapier version switch x.x.x)

I wonder if we have a unique use case, it seems like the cli does everything except pull an existing version onto a local machine. This issue is markedly different than #413.

usecase

I am trying to automate deployment on our Zapier integration. We have 3 primary versions of our Zapier integration, one for local development (which is done using the UI), one for Staging (which is done using the CLI because we need better zapier version control and having it immutable in the UI is a plus), and one for production. I want to remove possibility of human error when setting environment variables and cloning.

Our versions look like this
1.0.0 local (always UI)
1.x.x staging (cli)
production x.x.x (cli)

Actually I was motivated to switch to the cli primarily because it was the only way to set a 1.x.x version when 2+.x.x versions existed to support our deployment pattern. After learning that the cli versions were immutable in the UI, and I could script the setting of environment variables, that was a huge plus.

Our deployment script looks like this

• zapier convert version 1.0.0
• set next staging version
• zapier push
• set env variables
• clean (delete the folder containing the conversion)

Any updates would make a fresh staging copy, all automated, all without any modification of code. This is simply for version control.

We would then test on our staging environment, make sure everything looks good and push to production

Our production deployment script would (ideally) look like
• zapier switch version
• set next prod version
• zapier push

Then we would test on our production environment, and then promote the version if all is well.

This unfortunately is not possible. We are forced to save the copy of the code which means that only one person can be in charge of the push process. My temporary workaround will be to have the production deployment also convert 1.0.0. But this has a very very unfortunate possibility of pushing untested code to production

I am open to learning about other forms of version control. But we want to continue developing with the zapier UI because of its ease of use for our entire team, and we want to continue to have reasonable, deterministic versions

I hope I've made a compelling argument for the usefulness of the ability to switch to a version or "convert" a cli version. I would also be happy with the ability to manage versions remotely. Like interfacing with version control without "converting" or pulling the code to a local machine.

[David Brownman]

@qhenkart thanks for this thorough report! We've been talking this over internally. There's a few things to address here.

It seems like the core request here is to be able to easily manage multiple pre-production versions (many developments and a staging). This is a workflow that we have some workarounds for, but isn't directly supported (though we've been looking into what that might look like).

I think ultimately, you want to be using an actual VSC (such as git) for your version control rather than different versions of a Zapier app. Specifically, I'd expect your production deploy script to promote whatever version was just tested and verified as a staging version (instead of creating a new, identical version).

We develop a lot of apps internally, and our process is something like this:

1. Have all CLI code in a repo
2. make a branch w/ changes, push a new version to test on
3. once testing is ready, make a PR on github.
4. Once that's approved, merge
5. run zapier promote on the version created in the branch
6. run zapier migrate to get users on the new branch

The Visual Builder is a great interface, but when you're doing complex version control tasks, it's usually better to "graduate" to the CLI and have access to more standard tooling. You could git clone to a fresh spot and run scripts that way. Like with 413, zapier isn't really supposed to act as source control.

---

Another option is to make separate apps entirely: MyApp and MyApp (Staging). When doing any operation on an app, the CLI reads the .zapierapprc file in the root of the app. It's a little JSON document that, among other things, has an id, which is your app's ID on the server. One option for you could be:

1. Develop in Visual Builder
2. zapier convert
3. change .zapierapprc to point to your existing staging app id
4. increment version
5. zapier push; to manual testing
6. if successful, update .zapierapprc to the production app id
7. zapier push, promote, and migrate

This was you're using the same code base, but pushing it to different places as you go. As an added bonus, pushing a new version of an app copies the previous version's environment variables, so you might have less management to do this way.

---

Also, one thing that doing a bunch of zapier convert from the UI makes you lose out on is unit tests. We've got a pretty extensive unit testing framework for all our apps, but that's CLI only. So you might be able to have a simpler system if you can run unit tests against code rather than doing all verification manually.

How does that all sound?

[Quest Henkart]

@xavdid thank you for the detailed response. I appreciate you providing alternative solutions and the testing framework is something I will investigate.

As you said, I think the key issue is that pre production environments / versions are not directly supported, and the documentation is lacking in that regard as well. The end result is that teams, like in our case, might develop their own workflow before encountering the cli or finding a more idiomatic solution.

I think, ultimately, the flow that you guys use internally makes the most sense and it's something I will look into on our next run through of product development around Zapier. But I would have likely found another solution if I read that at the very beginning of my interaction with Zapier, due to the initial overhead when compared to the ease of developing in the UI. In the end I developed a script that supports my original intention by simply requiring the same person to push to staging to push to production, and I'm happy with that for now.

I think the challenge of creating a system that supports the pre-production cycle of so many different types of teams, products, and workflows is an especially challenging and interesting problem. Especially with two major entrypoints into zapier development. I am happy to offer more insight into how our team interacts, develops and deploys Zapier if your team is ever looking for UX research around the issue

Thanks again