Quick & Dirty TeamCity (from zero to CI in no time)

IMG_20150711_145030Attending CodeStock 2015, I attended the session “Quick & Dirty TeamCity (from zero to CI (continuous integration) in no time)”.  Below are my notes while in the session.

The session was presented by Joel Marshall @joelmdev.  Thanks for the excellent presentation Joel!

In short, this is using TeamCity (a product with a web front end that lets your developers deploy their apps and giving you the ability to control the building of their product, in addition to automatically running their unit tests and stopping the build (or the ability for another product to deploy) if any of the unit tests fail).  TeamCity can also monitor your source control provider to automatically detect new commits and build them.


  • Why TeamCity?
    • Free version supports up to 20 build configurations.
  • Installed build agent and server.
  • Set port to 8080 on dev machine so it doesn’t interfere with local IIS.
  • Edit your firewall to make a rule to open port 8080 if you want others to connect (if you’re setting up on your dev box.  If you’re setting up on a real web server, you’ll be using port 80 and won’t need to open any ports).
  • He set it up to monitor a BitBucket Git repo.
  • He then set up a build configuration and had it retrieve and build source from his Git repo on BitBucket.
  • There are all sorts of things that can happen during build and  you can configure it to take different actions on the results of each build step.
  • Miraculously, Joel successfully configured everything and got it all working.  He said he was more surprised than we were that he got it all working during the live demo.

My Comments on TeamCity (unrelated to the session)

I’ve been using TeamCity for about three and a half years (as a user, not an administrator) with 2 different companies.  I highly recommend this, in addition to using OctoDeploy (also with both companies for the same time period… OctoDeploy can receive builds from TeamCity and deploy them to different environments).

Why TeamCity?

In a company environment with multiple developers, you really don’t want your developers just handing you compiled code, asking  you to deploy it.  You should be publishing compiled code created from source code you have and from YOU building it.

TeamCity builds a deployable product from source code it gets from your source control repository.  The builds are version tagged and connected to the version it came from in Source Control.

If there are any problems with the build or running of unit tests, it will log it and provide you and the developers information on the errors.

You can configure multiple builds for the same product.  For example, you can have one build configuration for a testing environment, another for a QA environment, and another for a production environment.  As you know, all environments usually connect to different databases and web service servers, etc…   TeamCity gives you tools to change the config files from the source to make it work properly with the environment it’s working with.  In Visual Studio, developers can create web.config transforms that provide dev, QA, test, & Prod version (or as many as you like) of their web.config files and TeamCity can automatically recognize them and use the appropriate ones.

Once the product is built successfully, you can use another product to deploy the built code to the proper servers.  OctoDeploy works great with TeamCity and can auto-detect builds from TeamCity and automatically deploy them, or hold them, waiting for permission to deploy to certain environments.

Every production shop should be using tools similar to these, if not these.  It saves so much time and effort and provides an audit trail of what was published and ability to easily roll back bad deployments.  It makes building and deploying a real “thing” as opposed to just some random developer making changes to a production server with no accountability.  As a developer, myself, I want this, so I can’t be blamed for taking down a production server.  I do NOT want access to the production servers.

In addition to all of the advantages above, if you have weird stuff you have to do with any particular build/deployment process, you can automate just about all of it.

Leave a Reply