DevOps CI/CD Pipelines For Rapid Value Realization

May 30, 2017 |

Today, a lot of organizations are embracing DevOps by implementing CI/CD pipelines for their products. Depending on the maturity level of an organization the CI/CD pipelines are adding value in terms of time to market. It is important for organizations to realize that CI/CD pipelines with right automation, should be built to address the production deployments and the issues that can occur in production deployments. Unless these two attributes (viz. kind of testing and product deployment environment) are not factored in, the benefits derived out of CI/CD pipelines won’t serve the purpose.

Following is a way most organizations are implementing CI/CD pipelines. Depending on the maturity level of an individual organization, the actual implementation would vary in terms of tools that are getting used and individual activities that are performed during the pipeline execution.

Traditional DevOps Deployments
Traditional DevOps Deployments

The Issues

CI/CD pipelines implemented this way have few of the following issues:

  • The pipeline is focusing on just one deployment environment which can either be staging, pre-production or production. In most of the cases, it is just the staging environment which is controlled by R&D engineers.
  • Typically the type of test cases executed are unit test cases with very less (or no) focus on test cases related to the security of deployed solutions and infrastructure onto which the solution will eventually be deployed.
  • Once a solution is deployed and tested successfully in one environment, promotion of the solution artifacts to further environments and their deployments still remains a manual process.

Due to this solution deployment in the production environment is delayed, resulting in a late delivery for the end customer and a delayed realization of its overall value.

The Solution

Let’s try to understand how solving each of the above would result in a rapid customer value realization.

Seamless support for multiple types of environment (e.g. staging, pre-production, production, etc.) – Adding seamless support for multiple environments allows the stakeholders to verify the behavior of deployed applications in those environments before it is released to end customer. In traditional deployments, this support is present in manual form and in certain situations solution owners have to go through ticketing systems and approvals before they can get access to the required environment. This adds up to the overall release delay.

Automation of artifact promotion through those environments –  Automating artifact promotion through different environment can easily be achieved but just automation is not sufficient to achieve the efficiency to deliver the solution. It is equally important to make sure that the artifacts which are verified in the initial environment are not tampered or overwritten while they are getting promoted or deployed in next environments.

Execution of relevant test cases in each environment – For every environment the type of test cases that are getting executed change. For example, the number of functional test cases getting executed in the staging environment is much more as compared to pre-production and production. While testing the solution it also becomes important to verify the security and infrastructure aspect of the solution. Especially the way a solution is deployed in staging will vary from the way it is deployed in pre-production and production. For example, while deploying the solution in staging environment certain resources like database, load balancer, etc. could be reused to make optimum utilization of resources allocated. This will not be the case in pre-production and production environments. Not to mention right checks and boundaries in automation are required to avoid recent scenarios like the S3 outage. Below is a modified deployment workflow based on the above observations.

Multi Environment Deployments
Multi-Environment Deployments

Achieving rapid customer value realization depends on multiple factors. Automating majority of workflows and considering the set of individual point products as a single solution as compared to individual products is just one step in making sure that we are not increasing or adding on to the delay in solution release. Further testing the entire solution not only from a functional perspective but also from security and infrastructure perspective always provides an assurance that the solution once deployed in production would function in an expected way.

End Note

At REAN Cloud, not only do we practice security and compliance best practices for the infrastructure we build for our clients but also advise clients on how to instill a DevOps culture and practice with our platform. We understand that to have a successful business transformation, there needs to be a buy-in from senior leadership AND developers, and also have the right mindset and philosophy to use the DevSecOps principles daily.  Please contact us at info@reancloud.com if you have a question or would like to learn more about how we can help with your DevOps and business transformation.

Related Blog Posts

Blog

Top 5 Reasons to Utilize Cloud Computing in Financial Services
Read More
Blog

Is Migrating to the Cloud Safe for Financial Sector Companies?
Read More
Blog

REAN Cloud is one of the few AWS Premier Partners to achieve both AWS DevOps Competency and MSP Designation
Read More
Blog

7 Ways DevOps Can Save Your Company…Time and Money
Read More