DevOps Introduction (Udemy)

Old School Build and Integration

• The whole cycle may last from a couple of weeks to a couple of months. 
• One such cycle is called an iteration. 
• S/W dev team till packaging + instructions is Dev, rest is Ops. 

Old School Build and Integration Painpoints

• Integrating code
• Manual, time-consuming and Error-prone
• Integration happens towards the end of iteration so that's the only possible time when teams get to see the compatibility of their code with others' code. 
• Huge risk
• Developers might have moved to coding other modules.
• Consume lots of time and effort to debug - recalling the logic, etc. 
• Intermediate merges may hold up teams. 
• Long feedback cycles for functional defects.
• Long iterations

Continuous Build and Integration alleviates the above pain points [CI]

• A single central repository for code. 
• Developers check-in/commit code very frequently. 
• The Build is triggered every time a developer checks in code. 
• Automated functional tests run. 
• The build is automated and fast. 
• Build compiles the code and runs it. 
• Failed build shows up as a top priority to the developers. 
• Build results are communicated to all the developers. 

Old School vs. Continuous Integration

CI BUILD Pipelines

> All steps should be automated. No human intervention required in between.

> Run on a dedicated build server.

Old School Operations Model

Painpoints of the classical operations model

• The correctness of installation instructions. (Missing some instructions; cannot be guaranteed).
• The difference in instructions across different environments.
• All steps are done manually by Operations. Manual tasks are error-prone. 
• Deployments are sophisticated; high impact with downtime.

Continuous Delivery

Continuous delivery is a software development practice where software can be released to production at any time. 

Continuous Integration is a PRE-REQUISITE for Continuous Delivery

Script-based (Unix Shell Script / Windows Shell Script) automation is used to automate the deployment process.

    

Unlike continuous integration, continuous delivery need not be "fully automated". Most of the tasks in the Release pipeline are automated, but we may still have manual checks (QA checks), deployment button, etc. The final decision for deployment in the release pipeline still requires human intervention. 

• Quick
• Efficient
• Less downtime

Old School Operations VS. Continuous Delivery

Entire CI-CD Pipeline

• Some steps in CD are still manual -- manual testing & certification by QA. We already have automated UT and UI in build pipeline in the continuous build, but still, QA may want to do some manual acceptance tests.
• Acceptance Tests can also be automated as seen below (Automated UAT - in Test Environment). 

The automation team simply maintains the automation scripts. They do not intervene manually although they are shown in the pipeline (Diagram immediately above). 

Summary

Continuous Delivery --- is a software development practice where software can  (A choice) be released to production at any time. 

Continuous Deployment  -- is a software development practice where software is automatically released to production continuously. (No choice). Deployment happens continuously as long as all the previous steps are passed.

CD -- May mean Continuous Delivery or Continuous Deployment or Continuous Delivery / Deployment. 

Note - 

• Continuous Deployment is NOT COMMON. Only enterprises whose IT department has reached a very high level of maturity will go with continuous deployment. because of the risks involved. 
• Continuous Deployments need not always be big bang deployments. You can do a phased rollout for specific geographies.

FB does 50 production releases daily, which is about 1 every half an hour!