The main two major .mistakes that are made in setting up a TeamCity-based continuous integration and delivery system are:
- Putting the build agent software on TeamCity server (server hosting both TeamCity software and the build agent software).
- Installing TeamCity as a single server.
Although TeamCity allows you to to install both TeamCity web application and its build agent service on the same computer it does not mean that it is a good idea! Only for learning purposes can someone install both TeamCity software and TeamCity build agent on the same machine otherwise this setup is not good and will cause headaches. So why should not you put both the TeamCity 2017 web site and its build agent on the same computer?
- Because servers must be single responsible! One server should not have two responsibilities, which means your server must be either a TeamCity server or a Build Agent server.
- Because build agents run the risk of getting corrupt and you may need to kill them at times! If this happen then you will have to kill your TeamCity server too!
- Because you may want to take advantage of cloud build agents, in order to save $$$. If you set up your build agent on your server, you will not be able to terminate/stop your build agents when you do not use them.
- You cannot scale out your build agents. The more concurrent builds you have the more build agents will be spun up by TeamCity but if you put the agent and the web-app on the same server this cannot be done.
Also setting up TeamCity as a single server does not seem to be a good idea for being used in production capacity as it will not be able to scale out. The figure below shows a typical (and not ideal) TeamCity setup:
As you see the TeamCity server will be able to spin up multiple TeamCity Build Agents (if you setup cloud build agents) but it will not be able to scale out the actual TeamCity application. It will also not be highly available as a failure in the TeamCity Server will take down your CI/CD system.
In order to have a highly available and highly scalable TeamCity setup it is needed to use a centralised database such as SQL Server or MySQL so that all the projects, build configurations, templates etc can be shared amongst TeamCity servers.
Apart from a shared database, the data directory of the TeamCity servers have to be shared too so when you install the servers make sure you choose the same shared (e.g. network) location for all servers. You can also update the path of the data directory later via modifying the configuration file.
Speaking in Amazon Web Services language, in the above diagram, our TeamCity Serves are part of an Auto Scaling group, which means that as stress and load goes up on the servers, AWS will spin up more and more TeamCity servers.
If you want your set up be highly available as well you will have to make sure that your Auto Scaling group stretches across multiple availability zones (physical locations) too.
To learn more about CI/CD with TeamCity 2017 and AWS CodeDeploy, you can see this online course. I have set a very special price on this course for my blog readers 🙂