DevOps LifeCycle

DevOps Lifecycle includes Development and Operations teams working together. As Developers work on their agile iterations, Ops must work in setting up systems and automating the procedure of deployment. Automation is the key factor here, because agile model gives code repeatedly to deploy it on systems, that’s going to be continuous release of code and that must be continuously deployed to many servers in Dev, QA, Staging & Production environments.

• If the code deployment process is not automated then ops team must manually do the deployment. Deployment may include below mentioned procedures.
• Create servers if they don’t exist (On cloud or virtual env). 
• Install and setup prerequisites or dependencies on servers. 
• Build the software from raw source code (If not done by Developers). 
• Deploy software to servers. 
• Do config changes to OS and software. 
• Setup Monitoring. 
• Feedback & Report. 

NOTE-

All the above process may be less or more depending on the kind of deployment. We will discuss this in later chapters.
As soon as we get a new code change, it must be deployed to Production or at least staging servers.
For this, all the process must be automated, we must automate first Build and Release process which includes.

• Developers push the code in a centralised place. 
• Fetch the developers code. 
• Validate code. 
• Build & test code 
• Package it into distributable format(software/artifacts). 
• Release it. 

Next phase is to deploy this released software to servers, which we discussed already before this.Combining this Build & Release with Deployment process gives us the DevOps Lifecycle which is fully automated.

DevOps Engineers must automate all the above process it should be so seamless that when developers push their code to a central repository it should be fetched and run through all the above process and sends it to production systems.

As I say, “From Code to Prod”.

What is continuous Integration?

Developers will push their code several times in a day to a central repository, every time there is code change it should be pulled, built, tested and notified. There will be continuous code change so continuously we must do these steps. That’s why its Continuous integration. We have a separate chapter for this where it will be discussed in detail. As of now you can understand from above diagram that from step 1 to step 5 is CI

What is Continuous Delivery?

After CI, we should be also able to deliver our code changes to all the servers in different environments like Dev, QA, Staging. It should be automatically delivered to QA servers where testers will do functional tests, load tests etc. After it passes the QA tests it should automatically deliver the code to staging area where customer or some set of users can check the changes and give approval to deploy it to Production.

As per Wikipedia.

Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centres around the cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery. Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently. Thus, DevOps can be a product of continuous delivery, and CD flows directly into DevOps.

What is Continuous Deployment?

If the approval is manual process then code delivery is Continuous Delivery but if the approval process becomes automated then after staging, the code change is done directly to Production systems. This is called as Continuous Deployment.