DevOps Zone is brought to you in partnership with:

C# ASP.NET developer who works with MVC but is sometimes known to dabble with WebForms. Passionate coder who cares about his craft. Has a real want to create clean, readable and maintainable code. Obsessed with CI and its effects on a good development team. Pushing the bounds of continuous delivery and studying the advantages it brings to developers. Paul is a DZone MVB and is not an employee of DZone and has posted 25 posts at DZone. You can read more from them at their website. View Full User Profile

How to get started with CI - Series

08.10.2011
| 6301 views |
  • submit to reddit

About a year ago (July 2010), I started working with my current company. When I started the team were lacking in process and the process they had was not as useful as it could be for developers. The first thing I done in that team was to restructure the VCS and introduce continuous integration (CI).

The reason I chose these 2 practices first was that the team were not working as productively as they could be. There were no VCS regular check-ins and merging was hell. A good set of practices in VCS and a CI server to help spot merge issues up front was my idea of a step forward.

CI was a tough sell to the team. They didn't like the fact that it took time to introduce, they didn't like the fact that people could see everyone's mistakes and the company wasn't sure of the cost of the products and infrastructure needed. Originally, it was not fully understood why CI would be good for us and what it would help. I examined the current state of development and concluded that due to bad VCS practices it was becoming more and more difficult to ‘ship’ a version of the site. The points were how I eventually sold it:

  • earlier notification of integration errors
  • elimination of bad reference and dependency management
  • raising the confidence of developers


The team had a very bad management of references and dependencies in our visual studio solutions. There were GAC references and files missing everywhere. There was no standardisation of 3rd party tool storage. This led to deployment nightmares as there was a post release scramble to find missing dlls & files and FTP them to the live server. I was able to point out that  CI system meant we could find dependency issues and missing files faster (on every check in as it happens).

After a few weeks in place the developer confidence got higher. They were more confident of deployments and the team went from deploying once every few months to weekly then to twice weekly and then 3 times weekly. It became more of a lean production line as something was working on – checked into VCS and then the following day (or 2 days) it went live.

IF you are struggling with selling CI to your company or even if you are trying to introduce your company to CI then the following posts are a summary of the steps I had to go through to get CI integrated into our working practices. It started as a proof of concept, to demonstrate the benefits and it has grown exponentially for me. The posts are:

  1. Choosing the hardware requirements
  2. Choosing the correct tool
  3. How to integrate CI into your first project
  4. What is the potential of CI tools
References
Published at DZone with permission of Paul Stack, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)