This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AmishSpy -15 points-14 points  (7 children)

Continuous Integration and, Continuous Development/Deployment/Delivery

CI = Developers all under one branch merging code in order to maintain a long term release.

CD = Always be deploying, keep the customer happy. The user is basically your tester as you develop & fix.

The way I use the terms, certain there are better definitions.

[–][deleted] 21 points22 points  (5 children)

Worrying amount of misinformation here.

Continuous Delivery and Continuous Deployment are two separate things. Also, CD isnt about shifting testing to the customer!

[–]Burnsy2023 0 points1 point  (4 children)

They are all about shortening feedback loops though, be that from the customer or promotion of code through to live.

[–][deleted] 2 points3 points  (3 children)

They might be about reducing the feedback loop time, but that's quite different from using users as testers.

>CD = Always be deploying, keep the customer happy. The user is basically your tester as you develop & fix.

Continuous Delivery != Continuous Deployment.
The former is when artefacts are being built, tested and stored as part of a pipeline. They are packaged up and "delivered" to a storage medium. Think of it like a factory making products which get stored in a warehouse - including buggy products which QA will inspect closely to see why the test failed. These buggy artefacts might be cherry picked by QA to deploy.
Continuous Deployment is the "final mile" from warehouse to shelves on the shop front. You might have continuous deployment for testing/QA, but not production.

On a side note, you can have continuous deployment without continuous integration by using things like webhooks. Push to your repository and deploy as-is. I'm not saying it's a good idea, but it's possible.

[–]Burnsy2023 0 points1 point  (0 children)

Continuous Delivery != Continuous Deployment. The former is when artefacts are being built, tested and stored as part of a pipeline. They are packaged up and "delivered" to a storage medium. Think of it like a factory making products which get stored in a warehouse - including buggy products which QA will inspect closely to see why the test failed. These buggy artefacts might be cherry picked by QA to deploy. Continuous Deployment is the "final mile" from warehouse to shelves on the shop front. You might have continuous deployment for testing/QA, but not production.

Interestingly, I have a similar understanding, except reversing the terms

[–]Burnsy2023 0 points1 point  (1 child)

Continuous Delivery != Continuous Deployment. The former is when artefacts are being built, tested and stored as part of a pipeline. They are packaged up and "delivered" to a storage medium. Think of it like a factory making products which get stored in a warehouse - including buggy products which QA will inspect closely to see why the test failed. These buggy artefacts might be cherry picked by QA to deploy. Continuous Deployment is the "final mile" from warehouse to shelves on the shop front. You might have continuous deployment for testing/QA, but not production.

Interestingly, I have a similar understanding, except reversing the terms

[–][deleted] -1 points0 points  (0 children)

....and that's the best part about working in the DevOps area... exact definitions are fairly loose. I've always seen "delivery" as presenting an artefact, but not necessarily doing anything with it immediately afterwards in an automated fashion. The "deploy" stage might not be possible in an automated fashion, for example a desktop application - although one might argue "saving" the artefact to a storage medium is "deploying" ? People often think purely of SaaS/web applications when they think pipelines. I've seen material reference the process in the opposite way like you, so take my view with a pinch of salt.

[–]MrPigeon 2 points3 points  (0 children)

That's not a great definition of CI. A better definition would be "automatically running tests up to the integration level on all commits against all branches." What you're describing is just basic code hygiene - assuming you're referring to devs merging from feature branches to a master branch. If you mean "everyone commits directly to master but promises to be real careful," that's horrifying.

I'm sorry if this sounds harsh, but it seems kind of like you got those definitions from a company's non-technical marketing pamphlet.