In the afternoon your build could sit for over an hour waiting to start. And that was after we fixed a few obvious bottlenecks in the old setup already. It would take around 45 minutes (45 minutes, Carl!) to build our largest repo. We had quite a few regular complaints about our CI setup before migrating: Quite impressive right? In the remainder of this post, we’ll share why we did this and how we tackled this challenge. While doing that we standardized our pipelines, reduced the build/queue time, and took control of our build agent hardware and environment. We, therefore, migrated 75 repositories from Travis CI to TeamCity in a few months’ time. Was it really supporting our teams after the enormous growth we went through? Turns out, that was not the case. That’s why we took a hard look at our Travis CI setup last year.
Without a smooth build and test setup teams lose productivity and everything grinds to a halt. This is the general idea but not complete, by spending time getting this script out of the way you'll save a lot of time managing it via TeamCity UI.Continuous integration forms the backbone of every tech company. Set the agent requirement on the build configurations.įor each build configuration, in each project, set the agent requirements on the build configuration using the parsed out XX_VERSION value curl -X PUT -user username:password.Loop over all projects, get all parameters and parse our XXX_VERSION curl Get the XXX_VERSION parameter from the projects.Get the list of projects curl -i -H "Accept: application/json" -user username:password You'll write a single script (in whatever scripting language you're comfortable using) that you can run once to set all the agent requirements.
#TEAMCITY KOTLIN DSL UPDATE#
In this case, I think it would be worth your time to write a script to avoid having to go through the UI to update all the build configurations you mentioned. You can interact with the API using your preferred scripting language using HTTP GET/PUT calls to get and update values. Why not automate this using TeamCity's REST API? TeamCity's server has a built in HTTP API that you can use to edit/update (almost) any of the fields you would be able to using the web interface. It seems like you already know what you want to do and the issue is the large number of agents and configurations that you need to deal with. (Today, all our agents includes all possible versions of the software, but will no longer be possible, so we will need requirements on the agents from the projects of build configurations) But given the number of build configurations and the number of variant projects, I would prefer to parameterize the requirement on the value of the exiting env.XXX_VERSION. Now I also would like to include an agent requirement from all the relevant build configurations in the project so only the usable agents will be considered.
(Over time we make copies of this build project for different variants of some of the products we depend on, so we now have 12 different projects with different values for the parameters).
We can then use this value in the relevant build scripts of the project. can value include %.% substitutions?Īn example: we have a project parameters env.XXX_VERSION which specifies the needed version of the XXX product in all the build configurations of the project. In TeamCity, is it possible to parameterize the agent requirements based on project or build configuration parameters? E.g.
0 kommentar(er)
