This is my sense of how different it is from working in a Continuous integration (CI) environment to working traditionally. The traditional way of developing software brought smiles till the development environments start becoming complicated.
Things start breaking when several developers are involved and the traditional way of releasing a product becomes complicated when several developers started releasing their code to a single server at the same time.
There are many reasons why continuous integration is necessary, but none are so important, so essential, as “meeting the expectation”. Often we see that one of the fundamental failings in software development is the breakdown in meeting the expectations set by the business from Developers. Everything starts fine, with management asking the developers for the amount of time it will take to implement a feature. The developers provide an answer, and management takes them to their word.
Consider this, on an average developer, may view development as composed of the following steps:
- Determine what needs to be created or fixed
- Implement the feature or fix
- Manually check that their feature works or fixes the bug
- The job is complete. Move on.
The individual developer works on creating/fixing different features of a product and once their job is complete they take up the next task. By the time they reach a deadline, most of the time one of the results of the below situation:
- The product is still in progress/incomplete and is on the virtue of a deadline
- Or the Product is delivered, but it’s either faulty, creates new bugs, or both.
Any of the above two situations are neither good for management nor a developer. Without a doubt, we have lots of new tools, theories and practices, but in the end, we could never predict whether the product is going to be bug-free. All we could say is to learn from experience and try to make it better next time. The topmost fundamental reason for not meeting the expectation of the Dev team is –Impact analysis of the new changes, which might have impacted something on which another code is dependent, or tests pass on their machine, but fail on someone else’s or as the system continues to change, will their manual test still be applicable? If so how long would it take? Would the testing team repeat the test the same way every time?
There are so many unknowns, so many questions, and so many factors you can’t control. The possibility of being tripped up by anyone from the Team is extraordinarily high. By practising continuous integration at the core of your approach, the unknown becomes known, little by little. It holds the promise of providing proper application validation.
So what is CI?
Martin Fowler says – “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily leading to multiple integrations per day. Each integration is verified by an automated build (including a test) to detect integration errors as quickly as possible”.
And the main essential tasks of CI can be highlighted as –
- Maintain a single-source repository
- Make your build self-testing
- Automate the build
- Everyone commits to the mainline every day
- Fix broken builds immediately
- Keep the build fast
- Make it transparent
- Test in a clone of the production environment
- Make it easy for anyone to get the latest executable
- Automate deployment
Read more on the topic here: https://mikeciblogs.wordpress.com/tag/continuous-integration/ by Mike news
Some top benefits of using CI and why one should consider it from the beginning of your project.
Deploy your code to production: the CI server automatically deploys your code to production if all the test within a given branch is green. This is what is formally known as Continuous Deployment
Build Product now: Once all your tests are green and the coverage is good, CI servers can also trigger build and compilation processes that will take care of your needs in no time. The CI server will run within its scripts and notify you as soon as something goes wrong.
Build product/feature faster: With parallel build support, you can split your tests and build processes into different machines, so everything will finish even faster than if you run it locally. It will also consume less local power and resources, so you can continue working on something else while the builds run.
Detect system development problems earlier: Having your code tested before and after it is merged will allow identifying system problems earlier by decreasing the number of times
Reduce risks of cost, schedule, and budget: CI and Version Control Server communicates with each other and tells you when a merge request is good to merge. It can also show how the code coverage would be affected by it. This can dramatically reduce the time it takes to review a merge request. Continuous automatic regression test unit will aid in minimizing the cost, resource and time.
Continuous integration helps keep us to keep our process honest and transparent. It validates our assumptions and changes. And it is a process we can use in every moment of our work day to ensure that the software we are building is improving and not decaying.