Simple deployment process in middle-size project, #1: general overview

Loga TeamCity i Octopus
Ten wpis to część 1 z 2 serii ATM Deployment

The set of next few articles is prepared for ATM project members that would like to learn how to use and maintain our deployment infrastructure. However, if you want/must set up your own simple toolset for automatic deployment, I think you will find here at least few tips that you’ll find helpful. The articles don’t contain complex or sophisticated solutions, but are focused on the simple goal: make it work with as less effort as possible.

Every project that meets one or more requirements:

  • a size bigger than micro
  • developed by more than one contributor
  • developed for money

Must (or at least should) have infrastructure that automates everyday routines like build the latest version, check for errors, run tests, deploy to test servers for further manual testing.

Our project – ATM meets three out of above three points, so we had to prepare such infrastructure. As I’m a simple developer with no inclination for DevOps stuff, I had no previous experience with such things and I wanted to prepare it as simply as possible. I think it succeeded and now we can benefit from our own deployment infrastructure that consists of main platforms:

  • Github private repository
  • TeamCity server
  • Octopus server
  • Virtual machines

The requirements that I received were:

„Prepare infrastructure that constantly validates the code and each night deploys releases to the virtual machine, for testers are able to test it manually”

So I did and now our current development-deployment process can be depicted by this simple algorithm:

  1. Clone ATM repository on your machine. The preferred tool for interaction with Git is SmartGit – we have a license for it, so if you don’t have your favorite tool, try this.
  2. Often commit small packs of implementation. Commit message should look like: „B-XXXX,TK-XXXX: Explanation what this code does„. B and TK are numbers of backlog items/tasks from VersionOne that are related to the commit.
  3. After pushing to the repository, TeamCity (configuration named Build ATM) builds the latest version and runs unit tests. If the build is green, then ok. If not, examine build log and correct the error(s). Strona główna TeamCity
  4. Once a day (after midnight) Deploy ATM (nightly) configuration is triggered automatically. It creates NuGet packages, pushes them to Octopus server and triggers the deployment to ATM Auto Deploy environment (I will explain it with more details in next article). Basically, it installs the whole project on predefined servers – currently 009 and 016. If you want your machine also to be added to the auto-deployment list, just send a request.
  5. If you need to deploy the latest version immediately, you can run the Deploy ATM build manually. This will again deploy to 009 and 016. You can also deploy latest packages on other virtual machines – mainly your personal testing machine. In order to do this, you should prepare release in Octopus – this routine will be explained later.

Strona projektów w Octopusie

Projects page in the Octopus

As you can see, all these 5 points can be sum up with a short sentence: „commit often, check for green builds, deploy to your virtual machine when you want to”. The procedure also fulfills the requirements I described above.

In the next article, I will tell how the TeamCity is configured and how to use it in details.Then we will see the same for Octopus and the cooperation between them.



Nawigacja po seriiSimple deployment process in middle-size project, #2: team city >>