Continuous Integration

Anyone that uses GitHub or writes any code in general can probably understand the need to commit early and often. One of the first lessons taught to us by our teachers and through numerous failures is that code is very fragile. If you go into a long stretch of coding and find it hard to locate what is causing bugs, like me, you probably forgot to commit every time you add a working piece of code.

Continuous integration is defined by Wikipedia as: “The practice of merging all developers’ working copies to a shared mainline several times a day”. CI is a development practice that makes it much harder to create problems in a build. While testing is not strictly a part of continuous integration, it is usually included as a part of the process. If a developer makes sure to test their code each time they commit, even perhaps automating the process, it becomes much easier to detect and locate errors.

Continuous Integration Model — from devonblog.com

For example, developing with a team can sometimes be difficult depending on each members expertise and attention to detail. If multiple team members are working on the backend of an application, making use of and manipulating the same data and/or variables, it becomes difficult to keep track of each change the other person makes. With the practice of continuous integration and testing, both developers know that there is a safe place to return to if there are too many issues. If all members of the team are committing multiple times a day, the team can be sure that the code they’re working on is up-to-date and reliable.

There are many additional steps that can and should be included in the practice of Continuous Integration when possible. Working with a clone of the production environment is a great way to prevent integration issues. It is very likely that a test environment varies greatly from an active production environment, preventing developers from finding important bugs. Due to the fact that Continuous Integration implies that a user should test on multiple environments, the need for automation becomes even greater. Automating deployment, testing and any other part of your workflow that can be will save a lot of time. Creating scripts to do this easily is an important part of the workflow. Having automated tests will prevent faulty code from being committed without notice.

As a student, using the practice of continuous integration would have saved a massive amount of time when working on group projects. When learning a new language, many students tend to write massive blocks of code in a session without any testing and with few commits. This practice ends up dragging out the process, and there have been many times I’ve spent hours debugging code that could’ve been prevented if we had just tested and committed every time we had a working function. When applying this to a business environment, continuous integration can save both time and money.

In summary, the most important parts of Continuous integration are:

• Frequent commits
• Automated tests
• Test code in both a test and production environment
• Avoid pulling broken code — ensure you pull from a working build
• Ensure good organization of repositories