![]() Also, TC doesn't make it easy to have a dynamic cache key like Circle does. Configuring the first TC job to export node_modules as an artifact, but this seems to take forever on TeamCity (>10 minutes for a large node_modules dir), compared to a few seconds on CircleCI. ![]() CircleCI has a nice way to do this: it lets you cache your node_modules directory with a custom key such as node_modules., using a hash of your lockfile ( yarn.lock or package-lock.json) – because the complete node_modules directory is more or less a function of the lockfile.īut my company won't let me use CircleCI. It takes about 3-5 minutes to run yarn (to set up node_modules), so I want to avoid repeating it on every Test job.Īlso, most git pushes don't actually change the npm dependencies, so the 'Setup' phase could often be bypassed for speed. This should make better use of our pool of four build agents (better parallelism), and it should make failures easier to pinpoint.īut I'm having trouble with sharing the node_modules from the first step so it can be reused by all four jobs in the Test phase. I want to split the above into six TeamCity jobs, using artifact and/or snapshot dependencies to compose them into the desired flow. The Test step has jumbled log output from 4 child processes, and it's painful figuring out what failed.(The Test subprocesses run in parallel, but this only shaves about 15% compared to running them serially.) The whole job takes too long – 15 minutes.In TeamCity verify that you can see the agents and that they are compatible with the build configurations.The CI flow for our Node.js app looks roughly like this:Ĭurrently, this all takes place in a single TeamCity 'job' with three 'steps' (the Test step runs 4 concurrent child processes). You might have to restart the TeamCity service for the changes to take affect (but shouldn’t be necessary). Start by uninstalling if the agent is already running, then install, register and start the agent service. The bat files that does that are found here: Once you have set the properties you got to install, register and start the service. This is set here: C:\TeamCity\buildAgent1\launcher\conf\nf This is set here: C:\TeamCity\buildAgent1\conf\buildAgent.propertiesĪnd for the service running the agent a new: Set a new path for the build agent, as well as a new port.įor example, we use: C:\TeamCity\buildAgent1 and C:\TeamCity\buildAgent2īefore we register and start the build agent as a Windows service we need to set some properties- as they all get the same defaults which means that you will only override an existing agent if you don’t.The push to Octopus is only made when and if all the prior builds are successful.Īdding several agents can be a bit tricky (unless somebody has a secret trick), here are the steps: What we have done now is change the build chain and installed more agents, and the client and backend services build steps are run in parallel as the client and backend services and tests are independent of each other. And as we only used one it could just run them sequentially, and that would take a fair bit of time. VCS trigger => Build backend => run tests => build client => run tests => push to OctopusĪ build agent is what runs the build steps. This is how the chain looked like (simplified): At the end, we would push the deployment NuGet packages to out deployment service, Octopus. If everything passed we would build the client, and if all that was good run the client tests. If everything went well we would proceed with running our unit tests and integration tests (as a separate build configuration- just think of that as a way of grouping related jobs). The things we would do was set the version number, compile the libraries, create deployment packages. On change in the repo (or if triggered manually) we would start the build configuration for our backend services. The process is what we refer to as a build configuration(s), and each contains a set of build steps. This service listens for changes in our GitHub repository and starts some processes when we check in changes. What a build agent is? Well, on our build machine we run an integration service called TeamCity. Some notes for my colleagues for when I’m not around to manage the pipeline.įor various reasons, mostly lack of time, we have been using just one build agent on our build machine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |