Release Management (CI/CD)

Oh man I do a lot of revisions, before we proceed!

In the previous topic of "Application servers" we have already seen how an application is built and what are the tools required to build a packaged custom-made application, now whenever a Developer (a coder) who codes the application in an IDE and then converts it into a Package this code and package has to be stored somewhere and from that storage area it has to be transferred to the actual server/VM where it's supposed to run as an Application

Ok now let us get to "Release management", This is another serious topic which takes time to grasp, when you encounter this term for the first time or try to google it out, you would find yourself swimming into an ocean of confusion, let me simplify and break it for you in simple terms.

Release Management is a Process (Basic sequence of steps) by which we copy software from one place (where its developed) and paste (where it is planned to run) it at another place.

Let us look at it in another way by focusing on the exact word "Release", Whenever a Developer builds a software, definitely that software would have many versions based on the bugs encountered or new functionality added or just basic security additions, these versions have to be "Released" or deployed in production and every such version is basically termed as a "Release", hence the name "Release Management" where you are managing the different Releases / Versions. Now how do you manage these releases, simple; by using a Tool which does Release-Management.

You need to understand that in a typical enterprise a single Application has to run in multiple environments such as UAT/SIT(for testing), production and more, depending upon your organizations IT Environment structure, you can have more environments such as Staging, Migration, Preprod, etc., but the whole point is that when you are trying to deploy a single application into so many environments with probably different releases at different times it can get highly complex to manage all that code with different versions and different versions of the builds/packages and then on top of that deploying (pasting along with scripts and commands so that they can run) on different environments at different times.

so, to simplify this entire process from software development to testing, deploying and upgrading software versions time-to-time and again deploying it in testing and production and other environments; we have to use a "Release Management" tool and the process is called Release Management

So, we went through all this reading of Release management, but the Topic has additional words called (CI/CD), what is that?

Remember I mentioned Release management is a process (Steps performed in a Sequence), CI and CD are nothing but Steps which are performed in a Release Management.

CI (Continuous Integration)

It’s a process where the developer is writing the code and submitting, post that automatically that code is getting compiled and converted into a Build / Package, normally in a huge organization there can be hundreds of Developers (coders) making changes on the code so it's very important that the changes are tracked and tested and accordingly approved or roll-backed in case of the test fails, CI gives you the power to pick up the code, review it, validate it and convert it into a build or a package which can be deployed on any application server instance.

I just gave you the general definition of CI but there is more to it, if you focus on the word "Continuous Integration" it means some kind of integration, what is that? In an organization where multiple developers can be working on a single application but different features, the code developed by Developer-A should be compatible with the code developed by Developer-B, if they both are independently working on the code for months and on the final day when they try to merge the codes and find out that there are hundreds of incompatibilities then that would result in a waste of "time and resources" and again a lot of rework may need to be done, this kind of issues used to happen in the past and was termed as "merge-hell", but now with CI whenever 2 or more developers are working on the same project but different features, the moment they do a code commit, the CI process takes the code and merges it with the code of the other developers and does an "integration testing", this helps the developer to know then and there itself that whether his code or any change is compatible or not with the other codes in the application, hence at any given point of time with multiple developers working on multiple features in a single application, you will always have a working "build/package"

Continuous Delivery

Ok, let’s talk about CD now, CD can be "Continuous Delivery" or "Continuous Deployment", mind you both are not the same and have a huge difference, if the Build generated in the CI process is picked up and deployed in an automated fashion on a test server or UAT server then the process is called "Continuous delivery" and only once the UAT testing is successful and approved by respective stakeholders it would be pushed in Production. whereas if the same build is deployed directly onto the production server then it is called "Continuous Deployment"

DevOps

Before we proceed please do remember that this entire process (Code-Commit-->Validate and Build-->Test-->Stage-->Deploy) is all automated, although there are much more granular level processes involved in this cycle but I have taken only the most common ones, here I would like to introduce another industry term which is used for this entire cycle; "DevOps", DevOps is a combination of 2 words; Developers and Operators, since in the good old days Developers and Operators used to work separately, with Developers only doing the coding part and Operators were responsible for deploying the code but now you have special teams "DevOps" who can do both "coding as well as deploying" via the CI/CD process, all these steps used in this cycle are also called as a DevOps Pipeline. Further if you add the security testing and code analysis in the DevOps pipeline then the terminology changes from DevOps to “DevSecOps”, “Sec” introduced for security

Important point to Note: Most of the BFSIs would always follow the "Continuous Delivery" model where the Build is deployed in UAT and the business would actually test the application in UAT for weeks and once they provide the sign-off and approval then only the Build would be deployed in "Production", In BFSI all applications are almost critical so directly deploying applications in production is a risky proposition so it would be always tested in UAT and based on approvals the Build would be manually deployed in Production, so if you are working in BFSI, my recommendation would be to always follow the "Continuous Integration and Continuous Delivery" model rather than "Continuous Integration and Continuous Deployment"