AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Dogfood artifact meaning1/2/2024 ![]() Primarily because they’re already being used extensively inside JetBrains, so we need to dog-food those that aren’t. Our main version control systems in TeamCity are Perforce and Subversion. Since all builds are run on agents and these agents operate even if the server has downtime, we have a TeamCity agent installed on the same machine as the server and it’s this agent that performs the upgrade procedure.ĭaily releases not only provide us with immediate feedback on the features we use, but also allow us to extensively test the stability of the product before making any public releases. Usually though nobody is at work at 6 am! Why 6 am and not earlier? Primarily because some people at JetBrains start work later in the afternoon/evening and stay well into the earlier hours. If all of the previous steps are successful, then at 6 am – time with minimal development activity at JetBrains – TeamCity starts a self auto-upgrade. If these tests fail, the package won’t be released. While the build is running, two developers from the team (Duty Devs) review all commits made by the team during the day and if they both agree commits won’t break critical parts of the application, such as areas responsible for running and scheduling builds and build agent auto-upgrade, they put a special tag on the build marking it as “safe for deployment”.Īfter the build is complete and package is ready, TeamCity runs a series of integration tests (a bit more on that below) against the newly compiled package. Here’s how it works:Įarly afternoons, usually around 4pm, while most teams are still working, we start a new nightly build that will compile a new TeamCity package. Things are completely different inside JetBrains however – we continuously deliver TeamCity every working day. Each one of these is usually preceded with an EAP program and several bugfix releases afterwards, which pretty much results in a release every other month. You probably might know that TeamCity usually does one major and one minor release per year. While it probably doesn’t come as a surprise to learn that we use TeamCity ourselves, in this post we’ll describe a few details on how the team uses it internally and how it’s evolved based on own needs. Since then, much of the functionality in TeamCity has been as much a result of our own requirements as that of our users, as we continue to use it throughout JetBrains daily. TeamCity was started back in 2005 out of our own need to have a flexible and powerful continuous integration server that could deliver functionality beyond the offerings that were available at the time. A day in the life of a TeamCity developer.NET technologies (MSBuild, NUnit, FxCop, etc.), Xcode, Powershell, Unix shell scripts, etc. TeamCity supports lots of different technologies and some of them are platform-specific, such as.
0 Comments
Read More
Leave a Reply. |