If we decide to not run C, we will not run the whole pipeline, which is definitely not what the user expects. Even if there are finished builds identical to C (run on the same sources revision), at this point the CI system cannot avoid running C, as upon finishing C, build B and eventually A must be triggered as well. If something triggered C, the CI system must obey it, because this is how the user configured it. This is exactly what TeamCity does for all build chains while they sit in the queue.īut if we trigger the builds one by one, i.e C is the first, then upon finishing C we start B, and so on, then there are much fewer opportunities for a CI system to optimize something.
Teamcity personal build code#
If we trigger the whole pipeline at once, all builds (C, B and A) will be added into the queue and, if the system already has a finished build which used the same source code revision as build C will, the build in the queue can be substituted with such finished build reducing the total build time of the pipeline. But if the builds in the pipeline are triggered one by one, then it will always take the same time to finish completely.įor instance, say we have a pipeline C -> B -> A, where C is the first build and A is the last: If the whole build pipeline is known from the beginning, then it is possible to reduce build time by making some optimizations. We also thought that traditional approach to triggering – when the next build of the pipeline is triggered after the previous one is finished – is limiting, especially in terms of optimizations that CI system are capable of. It does it even if the build chain uses different repositories and even if the builds use repositories of different types – Git, HG, SVN, Perforce, TFS. TeamCity provides source code consistency for all builds in the chain automatically.
You can spend time and achieve this consistency somehow via build scripts, but since many developers face the same problem, obviously this is the area where CI tools should help. Actually, any time when you need to combine results of execution of several parallel builds, you need to be sure all these builds have used the same source code. For instance, if you build parts of your project on different machines in parallel and then combine them in the last build, you must be sure that all of the parts have used the same source code. After all, if someone needs consistency, it can be achieved by sharing data between builds using a file system or by tagging the source code in the repository and then fetching the same tag in all builds.īut from our experience in the majority of cases users need consistency for all of the builds participating in the pipeline. Traditionally, when build pipelines are described, not much attention is paid to this problem. Source code consistency implies that all builds of a build pipeline will use the same source code revision. At the same time, in TeamCity a build chain is a DAG – directed acyclic graph, and as such a traditional build pipeline is just a special case of the TeamCity build chain.
The reason is that we have our own term: “ build chain“, which we feel describes TeamCity’s build-pipeline-related features better.įirst of all, while the word “pipeline” does not impose sequential execution, it still implies it. Although it is possible to setup build pipelines in TeamCity, you will not find the term “build pipeline” in the TeamCity web interface or even in our documentation.
0 kommentar(er)
