Real world use of build and deployment templates.
Trying to make our builds easier to set up, and templates look like the way to go. I have moved our builds to using templates, and that's working well.
When it comes to deployments however, it's considerably more complex, mainly due to how dependencies work.
We have several streams.
StreamA Build (which uses BuildTemplate) is a dependency on SteamA Deployment (which uses DeploymentTemplate)
StreamB Build (which uses BuildTemplate) is a dependency on SteamB Deployment (which uses DeploymentTemplate)
StreamC Build (which uses BuildTemplate) is a dependency on SteamC Deployment (which uses DeploymentTemplate)
Problem 1
The template has a dependency and this needs changing when setting up a deployment from the deployment template. Is there no way this can be automated or smarter? It's not even on the Create new Deployment page, you have to know to go in and change the Artefact Dependencies.
Problem 2
The deployment scripts often use parameters that originate from the dependency for example dep.StreamA_ContinuousIntegrationBuildDevelop.build.number
This obviously breaks when you change the dependency to StreamB, and shows as missing parameters in the script.
Is there a better way to do this?
Please sign in to leave a comment.
Problem 1:
Yes, the dependencies need to be redefined, as there is no way to unify them and no way for TeamCity to know beforehand what build configuration it should depend on. While some settings of artifact dependencies like branch filter and artifact rules can be parameterized, making it easier to redefine them each time as parameters, the dependent build configuration must be selected.
Problem 2:
You can parameterize the parameter to avoid overriding the script for each configuration. For example, create the build configuration parameter in the template DEP_BUILD_NUMBER with a value of %dep.StreamA_ContinuousIntegrationBuildDevelop.build.number% and use the %DEP_BUILD_NUMBER% in the script. Then, change the parameter's value in each build configuration created from the template.
Best regards,
Anton
Hmm, have tried the response to Problem2 today, and it's not working in the latest Teamcity build :-( Or I have misunderstood.
I have created a paramater in our build template called DEP_BUILD_NUMBER set to this
%SoftwareStream%.%build.counter%
However it doesn't resolve this, nor is it even visible in the deployment template. Perhaps it's how I have set up the dependency in the template?
Re-reading this again, it sounds like this just moves the problem from the deployment template to the build template?
The build knows it's full build number (build name), so can't TeamCity work it out from the dependency? Having a different dependency name is just something extra that needs changing every time a new deployment is created from the template
I am trying to minimize the work required to create a new software stream, as more changes = more errors to creep in.
What is the %SoftwareStream%.%build.counter%?
For me, it worked as I described:
1. The Build1 is dependent on Build.
2. The Build1 has a parameter DEP_BUILD_NUMBER with a value %dep.TeamCityTests_Build.build.number%.
3. In the Command Line build step, call `echo %DEP_BUILD_NUMBER%`, and it will output the build number of the dependent build.
So basically, you can have a parameter in your template, DEP_BUILD_NUMBER, in this example, with an empty value by default, and use it in scripts where the build number of the dependent build is needed. Then, when creating build configurations from this template, you will need to specify the correct reference in the parameter without any changes to the scripts required.
Best regards,
Anton
Hmm, still not getting this, where to define the DEP_BUILD_NUMBER? is this the build template or the deployment template? I have tried this in the build template, and it just shows %SoftwareStream%.%build.counter% rather than the actual values.
In answer to your question, %SoftwareStream% is the major, minor and release stream defined when the build plan is derived from the build template.
“Then, when creating build configurations from this template, you will need to specify the correct reference in the parameter without any changes to the scripts required.”
If I understand this correctly this moves the problem from needing a script change, to extra parameters needing to be overridden when creating a deployment from the deployment template?
How will users know what to override this with? I guess I'm not understanding why it needs to be empty in the template and how it differs from what we already have %SoftwareStream%
The DEP_BUILD_NUMBER is defined on the template where you need to use it, so the deployment template in this example, for it to have easy access to the dependent build's build number.
Yes, when creating a build configuration from the template, you will need to override the created parameters with the correct values. Still, it seems much more convenient to override the parameters rather than each script where you need these values. The users won't need to override the values. The values need to be overridden when creating a build configuration from the template once the dependencies are set up.
TeamCity requires the ID of a dependent build configuration, like in your example %dep.StreamA_ContinuousIntegrationBuildDevelop.build.number%, as the build configuration may have multiple dependencies.
%SoftwareStream%.%build.counter% - this construction won't work. It is expected that you see output as is. The value of the parameter is the text string, and you can reference other parameters in it, but (in the example of getting a build number of dependent build) it must have the result in the format %dep.<DependentBuildConfigurationId>.build.number%.
It is not required to be empty in the template. But if it is empty, it will be more convenient to see if the parameter was overridden when the build configuration from the template was created.
Best regards,
Anton
OK, thanks I now understand. For us, the build number is already defined in the build, and it sounds like there is there is no way to get this in the deployment if we use templates, and as the work is pretty much the same, changing the line in the a script to reference the new dependency name, as it is to change a version parameter. So when our users create a new deployment plan, the minimum they will need to do is:
I feel this is an area that could be improved. Perhaps being able to assign a "static tag" to a dependency in a template that can be referenced from the scripts, so when the dependency is changed or overridden in the concrete implementation from the template, it retains the same tag, and all the build's variables can be accessed via the static tag, not the ever changing plan name.
I would also be useful that when a dependency is in a deployment template, it's shown in the create configuration screen, when the deployment template is selected, so users don't need to go poking about in the deployment plan to change dependencies. The other issue related to this, is that until you relink the new dependency (outside of the create new configuration page), the % auto complete won't find your build project, which makes this whole setup quite messy.
I have 3x parameters I need to access in the deployment script from the build script, and each one needs defining individually when the deployment is created from the template, which is messy, given the dependency had already been relinked, with a new name.
TFS has a similar issue, and a plugin to solve it.
Variable Tools for Azure DevOps Services - Visual Studio Marketplace
Even more far out ideas, given the dependency is in the template, and it's overridden in the concrete implementation, TeamCity could work out what's changed and therefore what needs adjusting itself… That might be overly complex however.
I would like to suggest you to create a feature request in our issue tracker https://youtrack.jetbrains.com/issues/TW and describe your use case in detail. The development team will take a look into it and see what can be done.
Best regards,
Anton
Deployment Templates are of limited use when referencing build dependencies. : TW-88825 (jetbrains.com)