Typed Parameters and Continuous Deployment
As I hope you’ve had a chance to see for yourself, TeamCity is an excellent tool for continuous integration used as a core ingredient in the continuous deployment process by many teams and greatly loved for its cool features, flexibility in customization and plugins. This post doesn’t aim at covering all aspects of continuous deployment with TeamCity; today I’d like to focus on a powerful feature and yet not widely known feature: typed parameters.
Many of you have run a custom build at least once. If you’re not sure what a custom build is, you are welcome to visit our documentation for details. In short, a custom build is a build with modified parameters; it can be run from the Custom Build dialog:
Typed parameters is a simple user-friendly approach to customizing the Custom Build dialog behavior. Let’s go over a few scenarios to see how these parameters work.
Scenario 1: Accidental deployments
We’ve all had a few cases when we started a deployment process by mistake, accidentally clicking the Run button. It’s a good thing these deployments didn’t cause any errors or outages, but how do we prevent such behavior in the future? Just follow the steps below:
Go to the Build parameters step:
Click Add new parameter and then the Edit button:
Set Display to prompt. In this case TeamCity will always ask to review the value and choose the Checkbox type.
Next, modify your deployment script to execute only if the value is true and that’s it! No more space for mistakes! Now start a manual build by clicking Run Build.
Scenario 2: Authorization by password
When a third-party provider hosting our service doesn’t provide authentication by key, it means we have to enter the username and password every time we deploy a new version. That’s a pain, since our internal policies allow us to keep the username in the configuration files but not a password. Moreover, we don’t want the password from the server to appear anywhere in the user interface or build logs. Let’s see how we can we handle this.
Add a new parameter – Password, click Edit, choose the Password type:
and click Run.
Problem solved!
Note: TeamCity tries hard not to reveal the actual value of the password type parameter by filtering it out from the build log and other places. Check our documentation for more details.
Scenario 3: Deployment to different servers
We deploy a new version of our service in three steps:
- To internal users
- To beta testers
- To all users
Our deployment system accepts the stage parameter with the following values: internal, beta and all. If the value is not from the described set, the deployment process will fail. Certainly, a person starting the deployment step can change the parameter’s value in Properties tab, but what if they make a mistake? Or simply forget to change the value? Here is how we can prevent it:
Add a new parameter – stage, click Edit, choose the Select type and add options.
Click Save and start the build.
Select, checkbox and password are not the only possible options: Text field with Regexp pattern validation is also available. Read our documentation to find out the details.
Hopefully, I managed to demonstrate that a custom build backed by typed parameters is indeed a powerful way to set up the process you need. This post is just an introduction which should help you to get to know TeamCity better.
Dig deeper, experiment and … happy building!
Subscribe to TeamCity Blog updates
