Today, I am very happy to announce a feature that has been requested by many of you in the past. A lot of users have reached out to us over the years and inquired about the option to include manual approval steps to a Codeship build.
We have now shipped this feature. And I can tell you, this is a big deal for us! It’s the first time we’ve offered a manual intervention inside a build on Codeship, and we're doing it with the goal to allow you to get more control over your deployment strategies. Starting today, you can require a manual approval for them to be run on Codeship Pro.
With the addition of manual approval, it’s now easier to keep your deployment environments secure and control who has access to deploy and when deployments can happen. In this post, I will walk you through using the new manual deployment feature.
How Manual Build Step Approvals Work on Codeship
To use the manual approval feature inside your Codeship Pro builds, simply add a new
type: manual group step to your codeship-steps.yml file. See here:
- type: manual tag: master steps: - service: app name: requires-approval command: deploy.sh
This is a group step like any other and can contain multiple steps -- even push steps. The
tag you apply at the top level of the
manual group will apply to all steps inside the group.
Once you have a group step in your codeship-steps.yml file, a build will pause once it successfully gets to this step. See here:
Who can approve or stop the build?
Once a build is paused, any user with high-enough permission, which for now is any user in the Owners group, can either simply stop the build or approve it to have it continue on to the next steps.
Once a build is approved, you will see a new build run appear in the build object on your Codeship dashboard (by the way, did you know we recently shipped major updates to our Codeship Dashboard and our Codeship Pro Build Page?).
Things to know
As this is a first version of manual approval for us, there are certain rules we’ve put in place. We hope to expand the power of the feature over time, but for now here are some critical things to keep in mind:
Nothing after a manual step will execute. This means that manual step groups should be the last things in your build, and if you want anything to execute after, you should include it in the manual step group.
You are limited to one manual step group per branch or tag. This means a build chain right now is limited to a single approval step, though we would like to add longer build chains down the line.
Once approved, the pending steps will run as a new build, beginning to end, including the previously paused steps. This is to prevent drift in the environment between builds and to guarantee all previously successful tests still pass.
Only project owners can approve or stop a build in a paused state.
For more detailed information about manual steps for your build pipelines, check out this documentation article: Codeship Pro Build Steps.
When to Use Manual Approvals in Your Build Pipeline
There are a lot of great reasons that you may want to add a manual approval step to your builds. Here are a few examples that might prove useful for your team/organization:
You have organizational policies that disallow direct access to production environments for all teams.
You have infrastructure tools that can get in to race conditions if deployments are not monitored and controlled.
You want to control when a release happens but not worry about merging the PRs on the SCM side.
You have outside contractors that you don’t want to let inadvertently deploy to production.
New Codeship Dashboard UI
This update added complexity to our user interface. That’s why, alongside manual approvals, we are rolling out a slightly changed builds dashboard.
As seen earlier in this post, this view will group the original and the approved events as two separate build runs inside a single dashboard build object. For instance:
Manual Approval Steps for Codeship Basic
Right now, this feature is only available on Codeship Pro. We have work underway to standardize the feature set between Basic and Pro and hope to make all features available to all users later in 2018.
Your Feedback Shapes Our Product
As mentioned at the beginning of this article, we built this feature because you, our users, requested it from us and we feel that it truly makes a lot of sense. Just as with your suggestions for a Personal Build Dashboard and the usability of the Codeship Pro Build Page, we are listening and are implementing your feedback. Who better to tell us how Codeship can and should be used than our tens of thousands of users?
With that being said, this is a brand new feature for us. In a way, it’s a new line of thinking since it’s our first step in branching into a more dynamic and reactive build chain.
We’re super curious to hear how you want to use manual approvals, how you’d like it to work differently, or what you’d like us to expand on. With that in mind, please get in touch with any feedback you have or any issues that come up or leave a comment below so others can benefit from your thoughts!