Option to not trigger upstream builds even when pending changes are available?

I would like an option for builds (deployments) not to trigger upstream snapshot dependencies even when new changes are available, but to progress existing build pipelines from the same chain as the default option (i.e. without having to select the exect dependency on the Dependency tab of the Run Custom Build dialog).
I have looked at the various options provided by TeamCity but I can't find a solution to this problem.

Here's a model of a delivery pipeline:
[compile] -> [unit test] -> [package] -> [deploy dev] -> [deploy qc] -> [deploy uat]

Currently if a user triggers the [deploy uat] to deploy the same version/revision of the [package] deployed on [deploy qc] this will work provided there are no pending changes checked anywhere since [deploy qc] was deployed.
If instead pending changes are available for the [compile] build, the whole pipeline, including [deploy dev] and [deploy qc] will be run when [deploy uat] is triggered.

The reasons to want this is:

  1. My deployment task could be dependent on another deployment task, I don't want the upstream deployments to be triggered as this could cause all sort of trouble (e.g. the environment being deployed might be in use)
  2. When deployments are triggered manually, users may click on "Run" rather than "…" and fail to select appropriate dependencies, potentially triggering a cascade of builds that would choke the build agents for no real purpose (we have over 100 builds in some of our chains).


One workaround I have put in place to prevent (auto) deployments is to prompt users with a warning to select the dependent build by using a parameter, but this is not fool proof.

Another alternative is to educate users to use Promote instead, however there are drawbacks:

  1. Can be difficult to locate the right dependent on the Promote build dialog if many builds are present
  2. Permissions don't seem to cover the scenario where someone is only allowed to run the [deploy uat] build but nothing else. If they go the [deploy qc] build they will not have the option to promote the build.


The other workaround I can think of is of course not have snapshot dependencies for my deployments, but that will limit us by:

  1. Removing the ability to visualize deployment build & deployment pipelines
  2. Not being able to easily use dependent properties
  3. Unable to see the changes from upstream dependencies



Does anyone know if what I want to do is possible with the latest version of TeamCity (we are currently using 8.0.5)?

6 comments
Comment actions Permalink

Hi Alex,

“Promote” button is used to perform deployment. See the related blog post http://blog.jetbrains.com/teamcity/2012/04/teamcity-build-dependencies-2/.

Do you actually need snapshot dependencies between "deploy dev", "qc" and "uat" build configurations? You can configure artifact dependency with option get artifacts from “Latest successful build”. In this case advantages of dependency will be preset, but the whole build chain won’t be triggered every time.


Also should "deploy aut" depend on "qc" and "qc" on "dev"? Probably you can configure "deploy dev", "qc" and "uat" depend on "package" build configuration?

0
Comment actions Permalink

Hi Alina,

Many thanks for providing your feedback.

With regards to promotion, there are two main issues:

  1. Can be difficult to locate the right dependent on the Promote build dialog if many builds are present [TW-40221]
  2. Permissions don't seem to cover the scenario where someone is only allowed to run the [deploy uat] build but nothing else. If they go the [deploy qc] build they will not have the option to promote the build. (I will raise a new ticket for this)


Snapshot dependencies are the way you define a delivery pipeline in TeamCity, if I remove it then I will not be able to use the features that I listed in my previous post.

I am trying to use TeamCity as a Continuous Delivery platform because it is marketed that way. For example, I want "qc" to be dependent on the succesfull deployment of "dev" as a way of controlling the flow of the deployments, which is a key part of Continuous Delivery.

Ragards,
Alex

0
Comment actions Permalink

We also have the related feature request in our tracker https://youtrack.jetbrains.com/issue/TW-35216. Please watch and for it.

0
Comment actions Permalink

Thanks.

I have also raised TW-40272.

0
Comment actions Permalink

Hi Alex,

I am finding the same problem here in order to appropiately model a CD pipeline.

We dont want upstream build to be fired, we just need to run the build configuration from the latest successful build of the previous step...

I have been evaluating Go-CD from thoughtworks and this concepts fits well within the application. Unfortunately it doesnt have the nice out of the box features Team city has like Nunit, DotCover, and a wide adoption in the market....

It would be great to be able to better model a CD pipleline within TeamCity.

Please let me know if you find a better way to deal with this cases.

Regards,

0
Comment actions Permalink

The only workaround so far is to use a "prompt" as described in this blog post: http://blog.jetbrains.com/teamcity/2013/05/typed-parameters-and-continuous-deployment/

This approach is not ideal as the prompt value is sticky, meaning if you check it once it will stay selected the second time, defeating its purpose, but it is better than nothing.

0

Please sign in to leave a comment.