71–76 of 76 posts
Continuous deployment is unprofessional.
Continuous deployment requires the highest level of professionalism and engineering process discipline.
Earlier quoted context omitted.
Continuous deployment requires the highest level of professionalism and engineering process discipline.
It's unprofessional. Anyone that is deploying things into a production environment without extensive careful testing and quality assurance is either selling something so dreadfully irrelevant that nobody cares if it's full of bugs and issues, or is putting others lives, jobs or wellbeings in danger.
Earlier quoted context omitted.
It's unprofessional. Anyone that is deploying things into a production environment without extensive careful testing and quality assurance is either selling something so dreadfully irrelevant that nobody cares if it's full of bugs and issues, or is putting others lives, jobs or wellbeings in danger.
Wrong. Extensive automated careful testing and quality control can be built into continuous deployment pipelines. (Quality assurance for defect prevention has nothing to do with continuous deployment one way or the other. Many people in the software industry confuse QA with QC.)
Earlier quoted context omitted.
Wrong. Extensive automated careful testing and quality control can be built into continuous deployment pipelines. (Quality assurance for defect prevention has nothing to do with continuous deployment one way or the other. Many people in the software industry confuse QA with QC.)
Again, no, you are wrong. You cannot do continuous deployment and quality assurance. The entire point of continuous deployment (or delivery or whatever they call it now) is that you are deploying constantly from master.
Quality assurance (defect prevention) activities are performed before code ever gets to the master branch.
Earlier quoted context omitted.
I'm in the same boat, but I feel like the problem is tying the commits to the user stories. Ideally you'd be able to make multiple commits to implement a single user story where it can't be done with a small amount of code.
Sure there are multiple commits on a branch, but when we merge back to the trunk the whole user story has to go in one shot. We can't put a partial user story on the trunk because then it wouldn't be in a fit state to release.
There are things that just can't be split apart, I admit. I had to do a truly heinous refactoring of some code awhile back to migrate from floats to doubles that couldn't be accomplished via a global find and replace (unsafe casts and other crap). That was the largest commit I've ever landed, and the code wouldn't compile for half the time I worked in that branch. Come to think of it, that refactoring was harder than it had to be because of duplication and badly written code, but it would've been massive no matter what.