Are there any samples of chained actions in practice? I have a scenario where I’m having to run a series of deployments through multiple builds of an app, so I can run a post migration script after each one to handle data changes.
Some deployments will involve running through 2 separate builds, some will involve jumping through 6 or 7 builds.
Hi Josh,
Sorry I don’t think there is anything beyond the docs are they are now. See the screen shot below for the shape of the data to pass. You can use OttoDeploy to get the JSON for a deployment, and a build. That’s what goes in that input property.
Do you have any specific questions I might be able to shine some light on?
Todd
Yes. I did see the chainedAction key/property and that’s what I was wondering about.
So, if I’m reading this correctly, I would pass in an array, with multiple json objects ( each object being the json for a deployment ). That’s helpful, and what I was looking for.
It would definitely be helpful to have a UI where we could build a template for various chained actions. Then in the deployment, point it at the source ( the original file with the data in it ) to start with.
One of the teams I’m working with has a version of this, and would be nice to be able to combine the 2 processes so we could just make an api call to trigger a chained deployment, and feed it the parameters we need ( like the source file ).
Well, that I know. And I’m very grateful for that.
I referenced a UI for building a template for the chained actions. For example, what we are using now ( in the screenshot ), which was built years ago and now just incorporates the DMT, allows us to build a template for each “set” of updates.
Example, one for going from version 1.35 to 1.40 ( which includes everything between ), another for going from 1.32 to 1.40, etc. Each deployment/migration happens, but there is also a specific updater file that goes and does a bunch of other tasks, data validations, data transformations, rebuilding custom configurations inside the file, etc.
So the piece that would be handy to have is a template for a deployment like this. Where we could specify the builds used for each deployment, and would look something like this:
Now, in addition to this template, we may have clients going from version 1.32 to 1.40. So we would have a separate template that chains those deployments together. And for each client that we move up to the current version, we could then just feed the source file to the template, and a new chained deployment is generated. And then I can run that deployment after testing it.
Note, what we are doing for this vertical product is a little more extreme than I’m asking for… but once set up, we run this whole process from another file that handles all of the copying files around, renaming, etc. What I’m really asking for is the UI to manage the chained actions. I believe the release notes mentioned this is a feature that was coming at some point ( 4.5 mentioned it, I think ).
Hi Josh.
We probably will have a way to pick from a list of actions in OttoDeploy at some point.
Frankly hadn’t thought of it as a way to chain version updates together. That is kind of interesting… and gives me some other ideas. Like what if you could contact an OttoDeploy file with Deployments setup for each version upgrade, you should be able to dynamically generate the chain of actions to take you from any two versions.
Todd
Sounds interesting for sure.
On a different client from the screenshot above, I had a similar scenario for a new project. I did that manually for a recent set of updates. It just made OttoDeploy very messy, because I needed to deploy through 5 versions on the production file, and 3 versions on the staging file. It was a “pants on fire” set of updates, so I didn’t have time to build out something else to call them using the JSON.
Hey Josh,
For your case, is there any reason you can’t do this with sub-deployments? Each sub-deployment runs its own post-deployment script and can pull from a different build, so if you’re doing everything on a single server there is no need to use chained actions for it unless you want to trigger the deployment after a build ends or something similar.
The sub-deployments don’t have the “templates you can chain together” part of this, although you could presumably make one massive deployment and only run the sub-deployments you need to by deselecting the others in OttoDeploy.
Chained actions are primarily intended for multi-server management of build-deployment chaining. They can call deployments on the same server, but that use case is also covered pretty well by sub-deployments.
Let me know if I’ve misunderstood!
-Kyle
Took me a minute see what you meant… but yeah, you mean to use the Use Alternate Source options. Yeah, I think that does what I need. Beautiful. Thanks Kyle.
