I have a different definition for each of the these steps.
First, for the Continuous Integration each commit is first run through a bunch of tests before actually merging to the intended branch if these tests passes then the changes are merged.
Second, the Continuous Deployment can be to a test or QA site for the users to see and approve the changes.Though this can be automated by integration and functional tests, it's always good an actual user tests the new changes for feedback and unseen bugs.
And then finally comes Continuous Delivery which would be pushing the changes to production once they're tested and approved.
The first two sound reasonable; the third one requires an approval process. Assuming this is a manual process it runs counter to the name. Continuous is without interruption, wherein your example (if indeed a manual approval) would not be.
This is one of the challenges for the DevOps community. How to clearly and sharply define terms, concepts, and goals such that the community accepts them and the business stakeholders can conceptualize them.
I do like the concept of assaulting the the change set to the test and quality checks BEFORE being merged into a target remote branch. Works well with 'branch often' workflows. With a little alteration it would probably work well in a 'trunk' centric flow as well.
Thank you for the input Jefry. I love talking tech. MEssage me some time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have a different definition for each of the these steps.
First, for the Continuous Integration each commit is first run through a bunch of tests before actually merging to the intended branch if these tests passes then the changes are merged.
Second, the Continuous Deployment can be to a test or QA site for the users to see and approve the changes.Though this can be automated by integration and functional tests, it's always good an actual user tests the new changes for feedback and unseen bugs.
And then finally comes Continuous Delivery which would be pushing the changes to production once they're tested and approved.
The first two sound reasonable; the third one requires an approval process. Assuming this is a manual process it runs counter to the name.
Continuousis without interruption, wherein your example (if indeed a manual approval) would not be.This is one of the challenges for the DevOps community. How to clearly and sharply define terms, concepts, and goals such that the community accepts them and the business stakeholders can conceptualize them.
I do like the concept of assaulting the the change set to the test and quality checks BEFORE being merged into a target remote branch. Works well with 'branch often' workflows. With a little alteration it would probably work well in a 'trunk' centric flow as well.
Thank you for the input Jefry. I love talking tech. MEssage me some time.