Continuous Integration

Introduction

Everyone is speaking about continuous integration. There is a buzz going around on what is continuous integration, what are it's advantages, which are the tools available,  which one to use etc. Well, we will start with answering the question "What is continuous integration?" 

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. It is simply a software engineering practice in which isolated changes are immediately tested and reported on when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. 

So what advantages does it bring?

Solve problems quickly from Thoughtworks

Because you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.

Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:

• Say goodbye to long and tense integrations
• Increase visibility which enables greater communication
• Catch issues fast and nip them in the bud
• Spend less time debugging and more time adding features
• Proceed in the confidence you’re building on a solid foundation
• Stop waiting to find out if your code’s going to work
• Reduce integration problems allowing you to deliver software more rapidly

Best practices of CI include:

• Committing code frequently.
• Categorizing developer tests.
• Using a dedicated integration build machine.
• Using continuous feedback mechanisms.
• Staging builds.
• Maintain a single source repository
• Automate the build
• Make your build self-testing
• Every commit should build on an integration machine
• Keep the build fastTest in a clone of the production environment
• Make it easy for anyone to get the latest executable
• Everyone can see what’s happeningAutomate deployment

How to do it?

• Check out code
• Commit changes frequently
• The CI server will trigger builds for every single change
• Then it runs unit and integration tests.
• Then it publishes all artifacts
• A build label can be added to the build output
• Mail will be sent out to the developers based on the result of the build.
• Developers should fix all issues as early as possible.
• Co-developers should make sure that they don't push code over a broken build
• They should also never pull the code from the repository which was failed in the CI server.
• Now, just go with the flow.

Tools used for CI

 Now the question is about the tools used for CI. Wikipedia provides a very big list of continuous integration tools available. But from my perspective , I feel that TeamCity is the best one. So the question, Why TeamCity?

Pre-Tested Commit: No broken code in your version control. Ever.

 The above image itself is self-explanatory. Unlike the standard scenario (edit, commit, verify), TeamCity's Pre-tested Commit feature allows you to remotely verify your changes BEFORE committing them to the VCS. 

 If your changes pass, TeamCity (in cooperation with your IDE) AUTOMATICALLY commits them to Version Control. If they fail, your code won't be submitted to the VCS and you'll receive a notification (by email, IM, your Windows System Tray, or in your IDE), allowing you to fix the failed code immediately. And unlike the standard scenario, you'll always know WHO broke the code. Most importantly, your team never stops working and there is never broken code in your Version Control.

And that's not the only big difference in TeamCity.

Other TeamCity features include:

• A Distributed build grid architecture — Your computer never slows down to run builds. You can simultaneously run builds for different Configurations (app servers, platforms, databases, frameworks, etc) — making Continuous Integration more continuous
• Remote Run — The same thing as Pre-tested Commit, on the Distributed Build Grid, without the Commit
• Server-side code analysis and code coverage — seen directly in your IDE (only for IntelliJ IDEA-based IDEs users for now)
• Tight IDE integration — allowing such things as jumping directly from an error report to the exact line in your IDE where the test failed — as well as many other features. 
• Rich web interface — with detailed and well-organized information.

NB: Taken from Jetbrains

In Jenkins…

• NO SECURITY by default? Why? TC secures out of the box. Common man. 
• No PreTested Commit – a TC standard that’s integrated with Intellij/Eclipse – Jenkins no intention to add 
• Defaults to port 8080 … way too common a port for DEV’s. Will conflict with all Java devs 
• Startup logs are to .err.log? Why? 
• Lack of timestamps in 2 of 3 logs
  Plugin install still triggers server restart, even if no plugins were updated/installed 

Choose TeamCity if …

Does many of the following apply to your case? If yes, then you probably need TeamCity:

• you are middle to large company;
• you have enough money to spend on CI. Not only now, but in the future as well;
• you need guarantees, that you CI works perfectly any time;
• you need the newest features;
• you expect most of the options, maximum flexibility and usability;
• you builds are distributed with some custom setup;

Advantages of TeamCity

• distributed build. Hudson and TeamCity do support distribution. TeamCity has some more options. So, just a tiny here;
• professional support. There is a dedicated firm (JetBrains) with skilled professionals. Hence, you can expect consistent code, good documentation etc…

And if you buy the licenses, you can request new features and plugins just for your special case.

• build from multiple VCS roots. One build, many repo locations;
• many advanced options, largest feature list. Example: it is not important for you if you don’t need Skype notification. But if you do, that may spare you weeks or more if this feature just happens to be already there. If not, Jetbrains will make it happen (only if you are a customer);
• large enterprise needs permanent partner. You cant expect the open source community to be your permanent partner. Yes, you can hire some contractors near to those projects, but it might be not enough if you are a big company. 

Conclusion

By adopting both Continuous Integration , you not only reduce risks and catch bugs quickly, but also move rapidly to working software.

With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fueling real change in your organization, and turning your release process into a business advantage.