Preparing for Continuous Delivery: Understanding your deployment process
1–5 of 5 posts
Re: Preparing for Continuous Delivery: Understanding your deployment process
#2I wonder how many companies are really using Continuous Deployment. Can somebody share their experience with that.? Is it feasible to remove QA people and dedicate that to developers?
Re: Preparing for Continuous Delivery: Understanding your deployment process
#3I wonder how many companies are really using Continuous Deployment. Can somebody share their experience with that.? Is it feasible to remove QA people and dedicate that to developers?
QA is one of the targets of a CD deployment, in some case they can be the primary target. Every time you check in you have a new QA deployment made, that can then get promoted to UAT production etc.
Having a CD pipeline doesn't necessarily mean you are deploying to production multiple times a day. It means you can if you wanted to. If I have customers experiencing a problem that I can fix with a 5 minute, low risk patch then going through QA is nothing but a waste of everyone's time.
Also, a lot of the traditional QA work would be automated.
Re: Preparing for Continuous Delivery: Understanding your deployment process
#4I've prepared packages and distributable for many enterprises and it's always CD as in continuous delivery not deployment, except on dev servers. A delivery may be a zip archive run via bash or powershell, or more of traditional msi packages and if necessary installed as part of the build pipeline. But remember, delivery means the package is delivered, it doesn't have to be installed.. But it could, and I've built releases this Week alone that large government agency here has allowed me to deploy as it contained just the change they needed.
Re: Preparing for Continuous Delivery: Understanding your deployment process
#5I wonder how many companies are really using Continuous Deployment. Can somebody share their experience with that.? Is it feasible to remove QA people and dedicate that to developers?
It's feasible, as long as you can tolerate a bug for a short time. The advantage is that once you notice a bug, there's less in the way of getting a fix out to production.
And let's face it: we're all tolerating bugs in production all the time.
As an aside, CD doesn't obviate QA or testing. It strongly favours automated testing over the manual flavour, especially during integration, but even then there's nothing stopping you from conducting manual tests on your branch before integration.