How an automated release looks like – the InRelease side

Once you have an automatic build leveraging InRelease for its automatic deploy, the workflow is pretty easy and straightforward.
Let’s say we make a whatever edit to a file in our project:

We check it in, and we trigger a Continuous Integration build.


Nothing too fancy at the moment. But of course we have to use the InRelease Build Definition Template for using those features, so we are going to see some specific activities in the build log, targeted at this.

The next steps are extremely easy and straightforward: depending on the Release Settings someone designed as Approver should approve the deployment:

Once this person/team accomplished this task, that’s basically all The only missing piece would be approving the Release (again, based on its settings. So it could be avoided, if needed)


A very useful aid is the possibility of scheduling the transition (i.e.: QA to Prod) to a future time, in order to be compliant with whatever company policy you might have.

And this is really all