DevOps! A must for modern software development, right?! You would expect most companies are already moving towards this new way of working. Why? Because software development needs to be more agile. Say you have a new customer, he wants a demo of your application but he also wants to see that one new feature. The software release that contains that feature is scheduled to be released in 2 months. Though, that specific feature is already “done and ready”. You ask the developers/administrators if they can put together a demo of that feature.. At that moment the devs and administrators are getting nervous. Everyone checks in their code to one single code branch so how are they going to demo that specific feature? Maybe on a laptop of a dev that still has a stable (*kuch* compiling) revision? This is where we have to change the way we develop software.
DevOps – What is it?
DevOps is a way of working – a culture change within your IT department. DevOps is focused towards faster software development, better quality and faster deployment of software. It focuses on concepts as Continuous Integration and Continuous Delivery. In the most ideal world you should be able to deploy a new version of your software within minutes, not weeks or months! Now don’t get me wrong, it doesn’t mean you should push every new feature or bug fix to your customers. It means you would be able to.
The old way
To build upon our small example as stated above. Let’s sketch an example organisation. This organisation has a large code base and over the years their application has become a monster. The old build and deploy processes are painstakingly slow and deployment of the software to production is not done without a prayer. There is a basic version control and branches are only made for major releases. Every developer checks his work in the main branch/trunk. Deploying the application from dev to test takes time. Builds break often. Efficiency is low.
The new desired way
So, how are we going to transition to a new way of working? What do we need and what kind of infrastructure will your IT department need? Let’s start at the beginning: version control.
Version Control flow
In the above image you can see an example setup for your version control setup. Let’s start with the development branch. This is the main development branch where the work of the developer end up. Note the side branches (features) though! Major changes developers work on, are branched of from the Development branch and worked on in an isolated branch. This way features can be worked on across time periods(sprints) without affecting the agility of the deploy process. Other developers can work on their own features and you are still able to deploy you application to a test or demo environment, even without that feature that isn’t finished all the way.. Whenever you are nearing a release I can imagine you branch of the development branch, make some final changes and take that version into production (and merge made changes back to main development branche!).
Currently there are a few solutions available for version control (Git, SVN, Mercurial, TFS). I would prefer Git though, because it handles large repositories a little bit better than SVN and has less overhead for each branch you create.
Continuous Integration/ Build server
The next step: automated build and CI (Continuous Integration) server. Continuous Integration means you check your work in several times a day. Each check-in is build and unit-tested by the CI server. By continuous building and testing your codebase you get early feedback on arising problems. This server also provides you with the binaries that are built (binaries, setup, etc.). During a project I was working on within a small team (±5 members), I was responsible for producing the installer. We had several components that eventually ended up in an installer for both 32 and 64 bit architecture. If you have to do that several times a day manually you lose a lot of productivity.. Automate it and be done with it in a press of a button.TeamCity, Jenkins, Bamboo and TFS are some of the popular CI’s out there. Personally, I like TeamCity a lot. TeamCity has a really user-friendly interface and is really flexible in the way you set it up. If you only need 20 build configurations and 3 build agents, teamcity is free.
Develop, Test, Acceptance, Production
If you still haven’t separated your DTAP environments, this is the time to jump in! Developers should develop on their own environment, push their changes to the CI, CI builds and unit-tests the software. Now you deploy your software to the test environment for testing and QA. This can be done manually (run installer) or automated by some CI servers or even dedicated deploy servers (Octopus). After the software is properly tested the software is pushed to the next environment: Acceptance. This environment closely matches the production environment. The release procedure is documented and the customer can have a look how the application performs and works under “production” circumstances. Finally the software is pushed to the production environment and delivered to the customer.
Infrastructure
So now we have clear overview of environments we need. But how do we organise all these environments? Each developer should have their own development environment. On simple projects testers could test on the same environment, but for bigger projects this tends to hit a friction point. Your application has an extensive set of configuration options and changing those settings hinders other testers and you hit a bottleneck. This is where infrastructure comes around the corner. We have done some substantial work to make continuous software development possible so why not leverage this power? Instead of having a few predefined develop and test environment we are going to virtualise these environments. By creating a centralised VM server where both developers and testers can create their environment we can continuously develop, deploy and test our software and be ready to take it into production! A solution to look into is VMware vSphere. With a vSphere server and using the vSphere client you can easily manage and spin up new VM’s.