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.
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 Blog updates
Kotlin DSL for Beginners: Recommended Refactorings
Imagine you have just switched your TeamCity project over to Kotlin DSL. Your builds run successfully, but what next? What small refactorings can you apply to your Kotlin DSL code to help keep it clean and tidy? In this article, we'll discuss the next steps you can take. 1. Remove disabled build st…
TeamCity integration with .NET, Part 3: Deploying projects
Today we are wrapping up our .NET integration demo. In this series, we've been explaining how TeamCity can integrate with .NET and walking you through a tutorial. To catch up with the demo, read the previous posts: Part 1: New approach and demo Part 2: Testing and building projects This project ha…
New TeamCity REST API documentation
TeamCity REST API is a powerful tool which lets you integrate external applications with the TeamCity server and create diverse script interactions. To make this instrument more useful and easier to understand, we have reworked the REST API documentation. Compared to a general guide we had in the p…
TeamCity integration with .NET, Part 2: Testing and building projects
In this blog series, we talk about the new approach we use to integrate TeamCity with .NET. Part 1 describes the .NET runner, that covers most of the core integration functionality, and introduces a demo project. In Part 2, we will dig deeper into the demo project and explore its Test and Build conf…