*Cross posted from my blog.
DevOps has a bunch of new goals, practices, and terms. Many of which are mixed up, misused, or just plain wrongly defi...
For further actions, you may consider blocking this person and/or reporting abuse
Your images and captions made my day. 😂
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.
Excellent article (images were good too 😂).
I’m currently exploring the DevOps world and I wonder: is “continuous delivery” to a non-production environment a thing? I mean, having an environment where actual users can experience the latest changes without putting in danger their everyday operations.
Great question Paula, welcome to the wide (but sometimes ambiguous) world of DevOps.
To answer your question: Yes, I would call that a partial continuous deployment.
To alleviate the danger to users have the development team hide new features behind a 'feature flag'. An easy way to do this is have features release version based. The code is on production but not accessible until the environment's version is incremented.
Hey David, a very well-written article. Kudos! As you said, continuous deployment is still not as widely accepted as Continuous Integration and Continuous Delivery. In that case, Continuous testing comes into play. With ongoing efforts to efficiently automate the whole SDLC, continuous testing will be critical. You might like to check out this blog that talks about how Continuous testing reduces software failures. Give it a read share your thoughts on it. Here is the link: cigniti.com/blog/how-continuous-te...
Glad you liked the article Hemanth. I'll give the article you provided a look, thank you.
Nice post.
For whatever reason, I reached peak clarity on this subject matter when I stopped trying to keep up with the trends on a granular level.
Now, if I were more specialized in this regard, I’d want to understand the grammar, but in terms of my day to day, I’ve happily accepted a less detailed mental model/vocabulary.
Really nice explanation!
I just use all three randomly in conversation lol
Well written, and this ...
Know the pain of adopting CI, well worth it though
Very true. Automated build / deploy processes changed my life.
Was enjoying the article already but had to scroll down to comment this early - I LOVE the images and captions, had me in tears. 😂 ok back to the article...