So what is the solution? It’s quite simple: Our team members will be working on any number of different projects at the same time, and as a result we have multiple projects deploying as part of our Continuous Delivery setup all the time and often at the same time – this can lead to a little friction, as developers can be forced to wait for their project to make it to the front of the build queue. So much so that my workplace’s love for CI and CD has meant that we have over 100 build configurations on our TeamCity server. If you have read my posts on CI in the past, you’ll know that Continuous Integration and Continuous Delivery are both something i am very passionate in my support of. Our staging environments auto deploy on check-in and our live environments have only ever been deployed to by our build server not direct from a users machine (they are executed manually) – this way our team always know that deployment day is a walk in the park, and there is no stress or tension when deploying a new feature. TeamCity is one of the greatest tools to hit the Continuous Integration world, with free licensing for 20 build configurations and an easy to use interface it ticks all the right boxes (not to mention ease of use for Windows Users) – but once you splash out on an Enterprise license and grow your installation to house many build configurations you start to want more power, and this is when a second build agent is your ticket to freedom.Īt my workplace all projects that we develop require compulsory continuous delivery.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |