In part one of the DevOps series, I discussed conventional SDLC phases, different teams associated with each phase, and issues associated with all of this. I also discussed how DevOps helps in ironing out most of these issues and introduces automation replacing various manual tasks.
For part one please use this link https://www.sachintah.com/post/devops-revisited-part-i
DevOps Best Practices
Let us discuss some of the best practices that need to be followed in order to implement DevOps effectively in a project life cycle. Following are some of the best practices
Continuous Integration (CI)
Imagine a scenario where you are developing a monolithic application with 25 developers and 4 team leads. These leads are responsible for managing 4 different modules. The team is following a typical SDLC model and uses GIT to check-in source code in a central repository.
Now, a developer checks in his version of source code in the repository and email respective leads to merge his source with the master. The team lead merges source code and then coordinates with other leads to integrate the application further. Once application integration is complete, team leads start building the application, and suddenly they realize one of the developers from 25 has checked in an inconsistent version of the source which is causing the build to fail. Now they trace down the developer and ask him to provide a correct version and the story goes on.
Can you imagine the amount of non-productive and manual hours spent on all of this? And this happens during the entire project life cycle. I am not even talking about other factors where team members are located remotely and in different time zones. So we can think of numerous issues with this approach. How DevOps can help here?
DevOps suggests a practice called Continuous Integration (CI). With CI, once a developer checks in his code changes into a central repository, integration and build process kicks off automatically and tests are run. Below fig outlines, stages of CI collectively called as CI pipeline.
Any changes in the repository kick off the build process automatically. If the build is successful you can perform other tasks in the pipeline. Now if the build fails your next task in the pipeline is not executed and you can trigger automated emails to the developer asking him to update the correct version. You can revert the commit which is not advisable in fact it is advisable for the developer to use a feature branch and not check in the code to the master branch directly.
Some of the advantages of using CI are
Frequent builds help in finding integration issues in the early stages of the project which also help in eliminating bugs in the project
Improves team productivity
Frequent delivery cycles for QA
Introduces cultural change and enforces frequent check-ins
Removes manual intervention and human dependency
Now once you implement CI in your project and build rejection starts to pop up for developers, there will be cultural change pushed automatically on them. Instead of checking in large code changes once or twice a week and face rejections, now developers will try to check-in smaller code chunks once or twice a day and make sure that the master build is successful and also their development environments are in sync with staging and production ones.
Continuous Delivery (CD)
Imagine a scenario where code is built and awaiting release to servers. Now release can be done on test servers, sandbox, or production servers depending upon the stage of the project. To do so, you may need to raise a ticket in some ticketing system, your ticket may follow an approval mechanism and eventually picked up by the administrator depending upon his/her bandwidth and/or release window/slot.
DevOps suggest a practice called Continuous Delivery termed as CD, where the application is built, tested, and then deployed to testing or staging/sandbox environment automatically.
It is suggested that before pushing any updates on production, manual sanity checks and approval process should be performed once. CD is considered as a step subsequent to CI and both are often termed as CICD pipelines.
CD automates your release cycle and therefore improves productivity, consistency and eliminates human dependency.
A QA planning to work on weekends does not have to wait for an administrator to manually deploy the application on test servers. CD also helps in achieving faster release cycles and time to market.
Below fig represents CI, CD, and Continuous Deployment pipelines as one single DevOps process. Continuous Deployment is a step further to CD, however, it is suggested to include some kind of manual intervention before going for continuous deployment for production release.
A step in the pipeline once completed successfully triggers the next step in the pipeline. Failure in one step halts the subsequent flow, for example, if test execution fails then emails should be triggered to the concerned individuals to take corrective actions and the next step is not performed. Continuous deployments may not be as frequent as CI and CD.
Infrastructure As Code
Imagine a scenario where you are required to perform cloud deployments with load-balanced servers and a DB server as well with mirroring capabilities. You should be able to do it in minutes if not hours using the UI interface provided by cloud providers like Azure or AWS.
How about replicating the same configuration for 20 instances worldwide?
Infrastructure As Code is a cloud-based practice in which infrastructure is provisioned and managed by code. These software and/or scripts are written by the software developer and/or administrator to interact with infrastructure programmatically and automate infrastructure-related tasks upon execution.
Almost all leading cloud providers expose necessary APIs and functions to support Infrastructure As Code.
Using Infrastructure as Code will benefit you with,
Provides consistency
Provisioning required infrastructure in seconds and at any scale
Use the version control mechanism on your infrastructure
Replicate infrastructural changes multiple times across different regions
Rollback or revert to any desired version
Azure comes with Resource Manager templates which can be used to manage infrastructure on Azure while AWS provides Cloudfront for management of your infrastructure.
Both provide the capability to display templates graphically. I will put up a separate article to cover this topic in detail.
Microservices & Agile Development
Microservices architecture fits well with Agile methodology and can be integrated seamlessly with DevOps automation. Since Microservice breaks down the existing applications into small independent units, it's easy to implement separate DevOps pipelines for these Microservices to increase productivity and provide frequent releases.
For more details on the advantages of using Microservice architecture, you can refer to my
Incorporating DevOps in a Project
DevOps can not be implemented overnight in any organization or in a project. Cultural changes and more importantly changes in the mindset of team members are required.
DevOps heavily depends on the usage of automation tools, therefore knowledge and understanding of DevOps tools also play a crucial role in implementing DevOps successfully.
Following are my insights on the steps you should follow if you are planning to take your first step towards implementing DevOps within a project in your organization
Use Version Control - Use of a version control tool and centralized code repository is a must in any project, you can go for GitHub, SVN, or a similar version control tool
Follow Loose Coupling - Huge monolithic applications your CICD pipeline may not execute smoothly and efficiently, use Microservice architecture or similar loosely coupled architecture for your projects especially for large-size applications.
Implement Agile Methodology - Typical SDLC waterfall model may not be efficient with DevOps as phase-wise release cycles are big with huge chunks of code delivered at once. Use Agile methodology to cut down release cycles and follow frameworks like Sprint or Kanban. With Agile you can have 2 weeks release cycles and DevOp will help in assisting the same
Implement Test Automation - Developers should learn how to write unit test cases for their own code, this helps DevOps in executing these test scripts during CI. There will be additional overhead on developers to write these test cases during development, however, it will be worth the effort Tools like Selenium should be used to write integration test cases which will be used by DevOps
Learn DevOps Tools - Hands-on working knowledge and experience on DevOps tools is also one crucial factor for DevOps success. Either train existing team members or hire a new member who already has expertise in DevOps tools like Jenkins.
Go For Phase Wise Implementation - You may want to go ahead with the partial implementation of DevOps, for example, start by implementing the Continuous Integration pipeline first before going for Continuous Deployment and Continous Delivery implementation
Advantages of DevOps
Effective implementation of DevOps can provide you with the following benefits
Automation - DevOps advocates process and task automation and therefore by implementing DevOps, you automatically implement automation in your project
Productivity Improvement - By using tools for process and task automation, you will achieve productivity gains which help in relieving team members to focus on other important tasks. Of course, the initial learning and implementation curve will be high, however, once done correctly you will surely reap benefits from it.
Shorter Release Cycles - Automation cuts down your release cycles and test cycles and therefore help in delivering your application faster
Consistency - Once implemented correctly, the CICD pipeline ensure consistency in the build and deployment process
Reliability - Your applications are more reliable as it goes via automated testing and release cycles
Scalability - Your model is scalable and can fit changes easily, be it a new member added to an existing team or new service addition to a project. With Infrastructure as Code, you can replicate your environment quickly and efficiently in different environments.
Security - Automating tasks improves application security since most of the compliance policies, secret keys are shared and take care of by automation scripts and not with individuals.
Happy Reading...
Comentários