While many engineering managers are aware of the benefits of CI and CD, few are prepared to define the processes to ensure smooth work flow.
We are in the era of Agile deliveries. Many engineering managers are aware of the benefits which Continuous Delivery (CD) and Continuous Integration (CI) can bring to any organisation. However not many talk about the day-to-day obstacles where if the process of CI/CD not followed meticulously, can our out to be major roadblocks.
QA and DevOps
If you are a Software QA and not sure about the connection yet , please read on
- Quality is not only QA’s problem any more
- Build promotions, CI and CD are not only DevOps problem any more
- More and more automation at Devops front
- Success of DevOps relies on a well disciplined QA practice
- DevOps is not killing QA
What could go wrong ?
Lot of agile teams today possess a common pattern of working model
- Multiple streams of work
- DoD (Definition of Done) enforces automation (DevOps, Testing, Processes etc)
- Continuous integration
- Automated Functional tests
- Continuous Deployment
Every single item from the above list is supposed to add value at multiple levels and felicitate quick and stable product delivery.
However release engineering and production deployment path becomes the most cumbersome travel in many places. There could be so many symptoms that indicates CI/CD flaws.
- Deployments are flaky/unreliable over time
- Often deployments exceeds allowed down-times
- Production releases becomes no lesser than a gambling.. (Yes - You heard it right)
- Lot of Quality issues/defect slippages
The Success of the release engineering and related practices highly depends on the nature of the team (Including Devs, QAs, DevOps). It depends on too many factors and it is hard to propose a single ready made solution to set them right.
I was trying to compile a list of issues that we have faced and possible reasons for the same in Agile delivery team. How about deriving a list of symptoms and corresponding possible reasons for the same.
Not sure the table can be used as a thumb rule but definitely this can be used a checklist for optimizing Release engineering practices.
There could be many other patterns and the above list is just an indicative one. It would really help if we continuously review the release engineering practices and follow/adopt the most relevant ones.
