Continuous Integration Approach
2 likes748 views
Continuous integration (CI) is the practice of regularly merging code changes into a shared repository. With CI, developers merge their code changes daily, which helps prevent integration issues. Automated unit tests are run on the merged code to catch any errors or failures. If all tests pass, the changes are committed to the main codebase. As code is built on the CI server, releases are automatically deployed to test, staging, and production environments on a scheduled basis. The goals of CI are to frequently integrate changes, catch errors early, and automate testing and deployments.
Continuous Integration Approach
- 1. Continuous Integration WorkflowContinuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. The main aim of CI is to prevent integration problems. CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. The developer executes automated tests against his code, and if they all pass they are committed to the mainline. This helps avoid one developer's work-in-progress breaking another developer's copy. As the codebase builds on the CI server, releases are then automatically deployed (on an agreed schedule) to the test environment. If tests are successful automated deployments are made to Staging and Production servers. · Maintain a code repository · Automate the build · Make the build self-testing · Everyone commits to the baseline every day · Every commit (to baseline) should be built Development Team (Scrum) Stakeholders Source Control (Development Server) CI Server Continuous Integration (Incremental Builds) Test Stage/Regression Production Sprint Demos (UAT) Automated Unit & Assembly Tests Automated SFT/SIT Tests Automated Pre-Production Deployment Tests Automated Deployments Automated Deployments Autom ated Deploym ents Automated Post Deployment Regression Tests Completed Release Completed Release Completed Release Queued Releases A C B D E F G H Automated Builds Tested Code Completed Code Continuous Reviews X=1 · Keep the build fast · Test in a clone of the production environment · Make it easy to get the latest deliverables · Everyone can see the results of the latest build · Automate deployment Best Practices A Stakeholders are represented by the Product Owner are effectively performing UAT at the end of every Sprint. B Sprint Demos are where the Stakeholders review progress on a continuous basis. C Development teams receive continuous feedback from Stakeholders through the Product Owner and the Sprint Demos. D Source code management and automated unit and assembly testing is performed, and then code is automatically deployed to the CI server. E Completed code is queued on the CI server until the Release Manager decides to proceed with promotion to Test. F Automated SFT (System Functional) and SIT (System Integration) testing occurs. G The Release Manager determines the scheduled to automatically deploy to Staging for pre-deployment regression and performance testing. H The final step is for the Release Manager to schedule the automated deployment to Production, where post production regression tests may be performed. Prepared By: Nigel Thurlow Last Updated: 10th April 2015 Version: 1