Developers can get tunnel vision. I am not saying this to judge, we can all get tunnel vision sometimes. I know for myself, when I get assigned a project, I get focused on that specific project. This can have a detrimental impact on any development project.
Every project has a timeline with certain features and corresponding deployment dates laid out. If specific developers are assigned to individual features, they may get so focused on their designated feature, they forget the potential impact it has to the entire project and timeline.
Enter continuous integration. Or the “production protector”, as defined by Dan Hill, one of our technologists. At a high level, continuous integration means that all the separate pieces of code are tested together to ensure that they work together. That way they can all be fixed together so that one developer fixing code does not mess up another developer.
Now for the details. Each developer on a project deploys the code they have developed to a shared repository. Using the continuous integration process, code is pulled from the shared repository and run through an automated test. If the code fails, the developers are notified that there is a problem with a feature that is affecting another feature. The developers are told where to look to find the issue without having to tweak each little section. If the code passes, the entire code is sent to the QA Team (Quality Assurance Team) for testing. All QA will need to test is the “look and feel” of the artifact because the continuous integration process will have already proven that the development pieces work. If the artifact passes QA, then it can be sent to production in exactly the same format.
This process means a faster push to production. The ability to run automated tests before the full code is handed to QA means less testing time. You don’t get stuck in the never ending cycle of fixing one feature and pushing to test, finding bugs, fixing them, and pushing to test, and on and on. Another benefit is an increase in quality of product. Also, speed of development is increased because developers do not have to go back and fix problems over and over, and this in turn decreases development cost. All in all, not a bad deal.
In short, if you are not using continuous integration, you should be.