Preventing accidental builds in TeamCity

Question

I want to create a manually triggered Team City build that deploys our website to its live environment. I am hesitant to do this as I worry about people accidentally triggering the build.

I know I could semi resolve this by preventing access for most people or by making the deploy process slightly harder, two steps for example.

Are there any nicer techniques? Is it possible to have a 'Are you sure?' style dialogue?

Answer 1

First off, you should take John Hoerr's advice and prevent people from running it unless they are a very small number of people.

But we can do even better, and prevent errant misclicks from people that should be able to run the build. Add a configuration parameter that's a checkbox. This way, when someone hits the "run" button, it will quickly fail. They'll have to hit the ellipses on the run button, then click a checkbox next to a message like are you sure?.

To do that, add the parameter with a name like confirm, then hit the edit link. On the popup, click the edit button next to Spec. Change the type to Checkbox. Set checked value to true, and unchecked value to false. Or some other values that make sense to you.

Click Save to save the Spec, then go back to the Edit Parameter popup. Set value to false. This is the default value of the checkbox.

As the first thing you do in the script, check whether the parameter %confirm% is set to the string "true" or whether it's set to "false". If it's "false" you want to exit 1 immediately: the person running the build did not check off the confirm checkbox.

If you want, you can make the Run Custom Build popup come up every time. To do that, in the Edit parameter specification window, change Display to Prompt. The default value will still be to not do the deploy, but the dialog will pop up every time.

You can also make the label that shows up next to the textbox not be the parameter's name, but an arbitrary string. In the Edit parameter specification popup, make the label something like Pinky swear that you want to do this?

Answer 2

The way that we do it is a two step process. Both steps have access limited to our deployment team. Let's use the production web server code as an example:

1. A build is manually run from Teamcity, building and deploying the production code to one non-public facing production server - the Deploy server. Due to our extensive caching and CDN use in production, this is a bit different than our Staging environment.
2. A second "build" is manually run from Teamcity, which is essentially just a trigger for a command line/powershell script to deploy the code from the Deploy server to the production servers.

Since both builds have their access limited, it prevents accidental deployment to production almost entirely. For example, if one of the few engineers who have access to the production builds came in and accidentally ran the second deploy script without running the first build, it would just re-deploy the code from the deploy server, which is the code that is already on production. This would not cause any damage.

While I certainly trust all of the engineers involved in our deployment process, I like the reassurance of a two-step process for production. Better safe than sorry.