Our build artifacts for the Integration-build (.NET) should consist of everything inside the results folder. Every C# project (.csproj) builds into its own subfolder which leads to the following folder structure:
For continuous integration builds we always build in Release mode therefore, we also have a subfolder Release in our structure. In my project we build everything into a folder called results inside our working copy. I remember having read about zipping artifacts before but never gave a thought about it until now. You probably read about it once you created your build configurations for the first time. Let’s check out what TeamCity has to offer first. Don’t start changing your build script and use 7-zip command line to achieve that, yet! Obviously we can save CPU time when we change our artifacts to a single large file. How can we improve and get our build faster? The approach And it causes a higher CPU consumption on our virtualized server environment. As we are running these 4 builds in parallel, we actually “only” lose 20 minutes with artifact resolving, but it’s still too much. So, it takes 80 minutes of CPU time just to resolve the artifacts in our build, which is triggered on every commit. Let’s have some numbers to see the impact on our build times: Resolving the build artifacts takes about 20 minutes for each of the 4 builds. Remember what you learned about reading and writing very small files from and to a hard disk? It is very slow compared to writing one large file with the same total size. Once from the Integration-build (.NET) build agent to the TeamCity server (artifact publishing) and 4 times to distribute them to the 3 test run and the create installer agents (artifact resolving). Now, keep in mind that the TeamCity system has to copy those artifacts 5 times per build (e.g. These artifacts are about 1.2 GB in size and consist of thousands of dll’s and other small files. You can see that the artifacts of the Integration-build (.NET) are used in four dependent builds: 3 test runs and the installer. In the above diagram you see the 4 stages in our build chain: build, test, installer, publish. Let’s have a look at our build chain first: In this post I’ll only write about how I implemented the improvements. In the next retrospective meeting my team decided that I should analyze the build process and implement improvements to get us back to fast build times. At some time we felt the build started slowing down. In the project I’m currently working on, we have a fairly complex build process with many artifact dependencies between the various stages in our build chain.
#Teamcity artifact paths software#
A fast feedback loop is of major importance, especially in agile software development. Read on to learn how you can get your builds faster and waste less time waiting for your builds to complete. You probably have the same potential for improvement as I had in my current project. Follow him on Twitter views expressed in this blog post are those of the individual, and do not necessarily represent the views of JetBrains.ĭo you work with build chains and artifact dependencies? Do you wonder why it takes so much more build time when your artifacts get bigger and bigger? Philipp is an enthusiastic software architect, agile coach, continuous integration expert and joint-owner of open source projects FakeItEasy and Appccelerate. This guest blog post is from Philipp Dolder, Software Architect and Continuous Integration Expert at bbv Software Services AG, a new JetBrains Training and Consulting Partner.
0 kommentar(er)
