For example, when we’re deploying to a different server or rolling back to an earlier build after finding problems in the target environment with a newer one. If we know the entire solution in a particular VCS revision has built successfully before and all the tests have passed, we don’t necessarily want to repeat those activities even though we may want to run the deployment process again. There are also times when we’re going to want to package and deploy without necessarily repeating something we’ve already done before. As I mentioned when we set up the build runner for the solution, that build may also contain unit tests and we definitely want those guys to pass before publishing the app. If another part of the solution contains errors – even though it might be independent of the web app – I don’t want to push this through to a live server.
#Teamcity environment variables series
However, we only want to do this if the build in the last part of the series has passed. It’s now all about building, packaging and deploying the UI layer and anything it’s dependent on. If there are other projects in the solution on which the web app is not dependent, they’re not going to play a role in this post. Breaking down the build and deploy processesįirst up, we’re now only focussed on the web application. The last thing to do is to harmonise everything so that we can actually automate the deployment. In the first four parts of this series we got config transforms playing nice, command line builds and packaging ticking along, Web Deploy happily receiving our application and TeamCity continuously building the entire solution on every commit. So here we are simply making Node.js scripts understand TeamCity system properties, that’s all.26 November 2010 << Part 4: Continuous builds with TeamCity
They are the primary means for customizing a build configuration which is based on a template or uses a meta-runner. Ant, MSBuild) as build-tool specific variables.Ĭonfiguration parameters (no prefix) are not passed into the build and are only meant to share settings within a build configuration. prefix) are passed into the build scripts of the supported runners (e.g. prefix) are passed into the spawned build process as environment. To recall, I’ll just quote the documentation:Įnvironment variables (defined using env. The only caveat is that it’s very important to understand the difference between three types of build parameters and when they should be used. Var tcProps = require ( ' teamcity-properties ' ) // not fail-safe var agentName = tcProps // throws if no such property var projectName = tcProps. Then our shell runners began to look like this: We’ve also tried to build simple CLI applications with arguments and options (see coa module, for example).
It’s that simple, but mostly uncomfortable and unreliable because of textarea editor without syntax highlighting and linting:
There we can access all build parameters (including configuration) through percent references: %project.name%. In TeamCity we use command line runner to execute our scripts. In frontend development our primary continuous integration tools for now is Bash and Node.js scripts. But same task may become more difficult in other development areas. NET build scripting tools such as Ant, Maven or MSBuild because TeamCity have a first class support for those and you can pass build parameters around with no effort. It’s easy when you’re working with Java or. To avoid copy-pasting build configurations in TeamCity and keep them DRY you should use configuration templates and build parameters. Edit Accessing TeamCity Build Parameters from Node.js