The Continuous Workflow
With Continuous Integration, developers integrate multiple times throughout the day and ideally commit to changes about once a day. Each change made is small, frequent, and shared to a single repository, making it easy to test.
Continuous Integration is preferred by developers because it allows daily constant feedback in development from all contributors and faster product time to market. Also since the repository of code is controlled, there is reduced risk to integrating all these changes in these small increments so often.
Additionally, it’s easier for testers to catch and resolve issues early in the process instead of waiting until release. When defects are found, they’re usually much smaller and easier to fix, reducing the risk of bugs in the final product and improving the overall customer experience.
In turn, this type of code integration leads to Continuous Delivery. Once the tests pass, the new build can be manually rebuilt and deployed by a PM or Lead Engineer who will usually check all systems before deploying. This also means that software that is pushed to the staging server and subsequentlly run through tests is always functionally stable and ready to be deployed at any time throughout the day.
Since code is constantly built, added, tested, and deployed regularly, new features can also be delivered on a daily or weekly basis instead of a monthly or yearly one. This means new features, functionalities, and fixes can be continuously released to the end user.
By constantly integrating improvement and catching problems early, teams find that software released under a Continuous Integration strategy is released more often and at a higher quality.
To take that one step further, Continuous Deployment is the automation of most, if not all, parts of your delivery life cycle including testing, building, and deploying.
Every change to the code base triggers a set of activities in your deployment pipeline, ensuring quality and delivering code straight to production if passed.