The DevOps (Developers + Operations) is a cultural shift that emphasizes on communication, collaboration and integration between developers and operations teams. There is many concepts evolved over the time under the DevOps title, like CI/CD, DevSecOps, etc. We will understand these basics of DevOps in this article.
DevOps Lifecycle
DevOps lifecycle usually involves following stages.
- Plan: Usually planned based on the feedback of last deployment in Agile iterations
- Code: Write the code, and check-in into team repository
- Build: Build the code
- Test: Run test cases on the build
- Release: Tag the release to the build
- Deploy: Deploy to various environments
- Operate: Operate the various environmets
- Feedback: Feedback provided through monitoring the environments
Basic DevOps Concepts
- Build
- Build is building your code and create binaries of your code blocks. If you are deploying on the VMs, it’s binaries and in case of clusters it’s container images.
- Artifact
- The binaries we built in the build stage (deployable binaries/container images) called artifacts.
- Deployment
- Deployment is the act of deploying your binaries you built in build stage to the various environments like dev, test, UAT, Prod, etc.
- Agile
- Agile is DevOps friendly methodology heavily used with DevOps. There are tons of articles on Agile implementation and other Agile related things, so I’m just skipping it.
- Scrum
- An Iterative, time-bound, and incremental Agile Framework for completing complex projects.
- Kanban
- A visual method of controlling activity that pulls the flow of work through a process at a manageable pace.
- Time To Value
- Measure of the time it takes for the business to realize value from a feature.
- Velocity (Agile)
- Measure of the quantity of work done in a pre-defined interval.
- Iterations
- It’s a single development cycle, usually measured as one/two weeks.
- Automation
- DevOps uses various tools to automate routine tasks for build and deployment. Heavy automation is required for quick turn around (feedback) on the new code check-in, if it’s working fine or breaking anything on the dev/test environment.
- Containers
- Containers are used to bundle binary packages we built in the build stage with all it’s dependencies for creating reliable deployment unit across all the environments.
- Continuous Integration (CI)
- It’s a practice that all the developers needs to follow to merge their code into the version control system daily/frequently basis. Means, each time you commit code, it’s merged with the main branch and build into artifact.
- Continuous Delivery (CD)
- Whenever a new build artifact is available, an act of automated deployment in the desired environment is called Continuous Delivery, except production environment.
- CI/CD
- Implementation of CI/CD means, the build and the deployment phases are automated but sometimes there is manual deployment for below production environments as well. And for production environment the deployment is 100% manually triggered.
- Continuous Deployment
- Implementing continuous deployment means automation from code commit to the production deployment. So the code changes pushed to live once it’s validated through test pipelines.
- DevSecOps
- Automating security aspects, embedding with DevOps workflow. It’s dev team + security team + operations team, so that the security becomes integral part of the application life cycle. For example in the build pipeline, once build is successful it will run the static code analysis tool which scans code for vulnerabilities, etc. and fail the build pipeline in case it detects anything. At each stage of DevOps, security is integrated with such steps inside.
- API (Application Programming Interface)
- It’s an abstraction layer, which abstracts out the communication part between the applications, modules, etc. It’s set of rules, that defines how to communicate with the underlying application, modules, etc.
- Everything as an API
- It’s one of the emerging trends, where everything has an API to communicate with each other or with the outer world.
- Monolith Application
- It’s an architecture style where application structured as a single process/container and single database.
- Modular Monolith Application
- It’s an architecture style where boundaries of each modules in the application are clearly defined in a single process/container with single database.
- SOA (Service Oriented Architecture)
- It’s an architecture style where you structure your application in such a manner that subsystems or tiers of the application decomposed as a separate service.
- Microservices with Single UI
- It’s an architecture style where we structures an application as a loosely coupled services with it’s own database.
- Microservices with per service UI (or Multiple UI services)
- It’s pretty clear from it’s title.
- Release
- One/More application changes that are build, tested and deployed together.
- Cloud Native
- It’s an approach to build, design and run applications on the cloud to take full advantage of cloud computing.
- Serverless
- It’s the cloud computing offerings where the computing resources required to run the application, provisioned automatically on demand or in response to some event(s) defined.
- Test Driven Development (TDD) or Acceptance Test Driven Development (ATDD) – Test-First approch
- It’s a programming approach for the software development where required are converted into test cases first (which are failed obviously because there is no code written to pass those test cases), and then code is written to pass those test cases. This way the development is driven by test cases.
- Business Driven Development (BDD)
- It’s a model driven approach, where business requirements are converted into business models and uses these models to drive the software design. It’s used for enterprise software mainly compared to the consumer facing products.
- Behavior Driven Development (BDD) – Test-First with shared business requirements
- It augments TDD or ATDD. First collaboration happens between the business people and the agile team to create shared understanding of requirements and then agile team will follow the TDD/ATDD appoach to implement those business requirements.
- Everything As Code
- It take Infrastructure as Code (IaC) and takes it to the next level.
- For example, Policy as Code (PaC), Security as Code (SaC), Pipline as Code (PaC), Configuration as Code (CaC), Compliance as Code (CaC), etc.
DevOps Metrics
DevOps metrics measure the performance and benefits of DevOps implementation. It also give insights into what’s happening at all stages of the DevOps pipelines.
- Deployment Frequency
- i.e. Before DevOps implemented it’s 10 deployments per month, now it’s 10 deployments per day
- i.e. Last month it’s 100 deployments, this month it’s 120 deployments
- Change Volume
- Last week it’s 110 LOC, this week it’s 101 LOC
- Lead Time (from Dev to Deployment)
- Last week it’s 3 weeks, this week it’s 2 weeks
- Failed Deployments
- Last week it’s 8 (10%), this week it’s 4 (5%)
- Mean Time To Detect (MTTD)
- Average time to discover an issue
- Last week it’s 7 hours, and this week it’s 9 hours
- Mean Time To Failure (MTTF)
- Average time system run before non-repairable failure
- Last month it’s 7 days, and this month it’s 10 days
- Mean Time To Recovery (MTTR)
- Average time to recover from a system/product failure
- Last week it’s 30 mins/issue and this week it’s 22 mins/issue
- Mean Time Between Failure (MTBF)
- Average time between repairable failures
- Last week it’s 2 days, this week it’s 1 day
- Mean Time To Repair (MTTR)
- Average time it takes to repair the system
- Last week it’s 4 hours, this week it’s 3 hours
- Mean Time To Acknowledge
- Average time to acknowledge the failure
- Last week it’s 2 hour, this week it’s 1 hour
- Incident Volume
- Last week it’s 18 incidents, this week it’s 25 incidents
- Availability
- Last week it’s 99.5%, and this week it’s 99.1%
- Response Time
- Last week it’s 3 seconds, and this week it’s 3.3 seconds
Conclusion
DevOps is a huge topic, but for the basics I think it’s enough understanding. Let me know if I miss anything in the basics of DevOps.