Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
A question comes to mind in what exactly do we need to do to move forward with Continuous Delivery and Continuous deployment, How should we start or rather where we should start from. Many times teams may not have achieved the continuous integration properly, maybe due to lack of proper tools, workflow or historical process.
What we need to do before even thinking of CI/CD, what are our prerequisites:
- Source code
- Builds System
- Deployments
- QA Automation
We need to understand release != deployment
Lets assume with the help of right source control tool, build system and QA, automation team has achieved the continuous integration which means developers integrate code into a shared repository several times a day and each check-in can be verified by an automated build, allowing teams to detect problems early.
The next step: From CI to Continuous Delivery deployment
What exactly is Continuous Delivery, Its attitude to make software safe and to go fast
Lets begin with basics, How much time does it take to deploy one line change or a small bug fix in to the production? Exactly, our goal should be to achieve this as fast as we can.
Why We Need Continuous Delivery?
- Yes, its Speed which is needed in current fast paced software industry.
- Stop waiting around on each other to provide go ahead and open the gate.
- Quality – It raises the overall quality of your application – No surprises.
- Capacity and Clarity – Get every team on one tool – Eliminate manual error
How are we going to do this…..
Key Areas:-
- Speed is essential because there is an opportunity and cost associated with not delivering Software
- Frequent Releases, How frequent is frequent? Why do developers need to wait after writing code?
- Every build can be potential release candidate.
Bottom Line
Remove Manual Work/Steps.
Move towards complete automation
Delivery Flow
Here is the Delivery Flow.
Ingredients:-
Configuration Management
continuous integration/ Automated Build
Automated Deployment
Automated Testing
Obviously no single team in a company alone can achieve CD without the help of other teams. It needs collaboration and team work to implement it, Lets take a look at what do we need from various teams
Dev Team
- Collaboration – Integration is no longer an event
- Check in regularly
- Make small frequent releases because Big Change -> Big risk –> Big effort and Small Change –> Small risk –> Small effort
QA team
- Should have complete automation or whatever max is possible. More manual testing leads to more delay.
- Keep the Build and Test Process Short
- Break the QA automation into small pieces so that they can run simultaneously and do the QA frequently.
- Publish the report
Environment
- Should have complete Environment to test everything.
- Flexible and scalable so that multiple env can be spawn any time and can be extended.
- Managed as prod or at least similar to prod
This increases Confidence in build’s production readiness reducing release risk.
Main blocker to achieve CD
- manual work
- Lengthy Process
- ticket system
- approval
Now, How do we deal with blockers
Do not add gates, add only checks. Adding gates to prevent issues from creeping into prod is not so smart. There are many more issues hiding, you just don’t know them
Approval!!! Why do we need CAB?
Dev Sign off
QA sign off
Ops and Dependency sign off
Infra sign off
Dev Sign off -> Use proper project mgmt tool to track everything that goes in to software with adequate workflow. Get everyone together at the beginning so that these will not be surprises at the last moment. Keep meeting across the team during entire development. This way you don’t need any approval since you have already taken care of all necessary elements during the entire development process.
QA Sign off -> Publish consolidated QA report with each and every build which should be visible to everyone. You should have proper definition of “Go Ahead” instead of just random checks, Nobody has to ask QA for a thumbs up for the go. • Minimum criteria for Q has to be set.
Ops, Dependency and Infra Sign off -> Include them at the beginning of the project. Have capacity and change planning during requirement gathering, This gives enough time for ops and infra to get ready for the release.
Role of SCM/ Release Mgmt
SCM/ Release Mgmt provide the workflow, tools and necessary filler to enable all teams to interact and automate their part.
The picture below shows How SCM and Release Management help each team.
Source code support for Dev by defining branching policy, Build Setup Support for Dev team to provide continuous build with predefined configuration and in managed environment which includes static code analysis like unit test, code coverage, checkstyle etc..
Enabling QA Automation and reporting via build tools (Like Jenkins) to support QA and Dev to run their automation and aggregate report on central location. which include QA automation/regression, functional code coverage etc..
Infrastructure for QA Support like managing integrating environment, Deployment Automation etc.
Ops, Dev and QA CAB Automation and release planning support.
It’s clearly visible that CI and CD is not a one man show. Planning, collaboration and teamwork are essential parts of the execution.
Tools can be chosen by the org/team whichever are suitable for them, but the main part is automation and integration of the tool with each other to make flow smooth and free.
