DORA (DevOps Research and Assessment) Metrics - dtoinagn/flyingbird.github.io GitHub Wiki

DORA Metrics ‐ Indicators of the Performance of a Software Development Team.

Through 6 years of research, the DevOps Research and Assessment team has identified 4 keys metrics that indicate the performance of a software development team:

  • Deployment Frequency - How often an organization successfully releases to production
  • Lead Time for Changes - The amount of time it takes a commit to get into production
  • Change Failure Rate - The percentage of deployments causing a failure in production
  • Time to Restore Service - How long it takes an organization to recover from a failure in production

At a high level, Development Frequency and Lead Time for Changes measure velocity, while Change Failure Rate and Time to Restore Service measure stability. And by measuring these values, and continuously iterating to improve on them, a team can achieve significantly better business outcomes.

Ansible

  1. What are the basic use cases of Ansible, Ansible Inventory, Playbooks, Modules, Variables, Conditionals, Loops, Handlers, Collections, Templates, and Roles?
  2. Advanced use cases:
  • How to handle errors during playbook execution
  • Use Ansible Vault for securing critical information
  • Develop custom modules, filters and plugins
  • Ansible best practices during playbook development
  • Use Dynamic Inventory in playbooks
  • Ansible execution flow using strategies
  • Retrieving data from external sources using lookups
  • Understand and develop templating using Jinja2
  • Develop and re-use custom roles
  • Ansible Galaxy
  • Developing playbooks

About DevOps:

Yes it's perfectly fine, ignore anyone who says Kubernetes as it's not actually needed in 95% of the cases.

I came from a cloud engineer background and sys admin background before that. Here's what you need for core competency coming from that world:

Containerization knowledge - Essential for DevOps and can span various platforms

Terraform (or other IAC) - Absolutely the number one thing you should know is some form of IAC

Bash or PowerShell - Either will be fine as they give you a base. You can pick up the other easily.

Python or Go - One of these for scripting at the minimum is good to know.

Read Code - Be able to read a couple different backend languages. You don't "need" to write them but have the ability to read and understand them at the minimum. The rest will come.

Networking - You have this in would bet but it's good to know base networking and deeper networking

Observability Platform - Chances are you are half way there with Monitoring Systems but learn the greater scope of something like New Relic or DataDog

YAML - Most pipelines and various other items will need YAML. Just worth understanding. If you used Ansible before you have that.

CI/CD - GitHub, ADO (Azure DevOps only for Azure workload), or GitLab are preferred here. All three are great but you can use others and still be ok. Those are the big boys in the space.

Systems Knowledge - While you probably won't work with a full VM. Having a core systems knowledge is super helpful even with PaaS services to understand how they function.

This varies from company to company buy that should be a good footing. I'm sure people will say "know Kubernetes" but really the majority of implementations put it in because it's a buzz word that requires tons of work. If your job needs it, learn it to help get the gig, otherwise don't worry about it right away.

Ansible vs Gradle

Ansible and Gradle are both popular tools used in software development and deployment. While Ansible is focused on automation and configuration management, Gradle is a build automation tool primarily used for building, testing, and deploying software projects.

  1. Programming Language Support: One key difference between Ansible and Gradle is the programming language they support. Ansible is written in Python and relies on YAML for defining configuration management tasks. On the other hand, Gradle is built on tope of the Groovy programming language, although it supports other languages, such as Java and Kotlin. This difference in language support makes Ansible more versatile for system administration tasks, while Gradle is better suited for building and managing software projects.
  2. Scope of Automation: Another difference lies in the scope of automation provided by these tools. Ansible is primarily designed for infrastructure automation and excels in tasks such as server provisioning, configuration management, and application deployment. It offers a board range of built-in modules to interact with various systems and services. Gradle, on the other hand, focuses on build automation and dependency management within the context of software projects. It provides a powerful and flexible framework for building, testing and deploying applications.
  3. Configuration Management vs. Build Automation: While both Ansible and Gradle overlap in some areas, they have different core functionalities. Ansible focuses on configuration management, where it ensures that systems are configured correctly and consistently. It is well-suited for managing complex infrastructures and automating repetitive tasks. Gradle is primarily a build automation tool that orchestrates the build process for software projects. It handles tasks such as compiling source code, running tests, packaging artifacts, and managing dependencies.
  4. Declarative vs. Imperative: An important distinction between Ansible and Gradle is the underlying approach to defining tasks. Ansible follows a declarative model, where the desired state of the system is specified, and Ansible takes care of reaching that state. This allows for idempotent and easy-to-understand configurations. In contrast, Gradle follows an imperative model, where the build process is defined step by step, specifying the actions to be performed. This gives more control over the build process but can be more verbose and harder to reason about.
  5. Learning Curve and Ecosystem: The learning curve and ecosystem around these tools also differ. Ansible has a simpler and more approachable syntax, making it easier to get started. It has a large community and extensive documentation, with many pre-built modules available for various tasks. Gradle, being a build automation tool for software projects, has a steeper learning curve, especially for complex build configurations. It has a thriving ecosystem with plugins and extensions for various use cases, but finding the right plugin and understanding its usage can be challenging for beginners.
  6. Deployment Target: Lastly, the target of deployment is another difference between Ansible and Gradle. Ansible is designed to work with a wide range of infrastructure, including physical servers, virtual machines, containers, and cloud platforms. It provides a higher-level abstraction for managing systems and services across different environments. In contrast, Gradle focuses on building and deploying software projects, primarily targeting application deployment to servers and cloud platforms.

In summary, Ansible and Gradle differ in their programming language support, scope of automation, core functionalities, task definition approach, learning curve, ecosystem, and deployment targets. These distinctions make them suitable for different use cases within the software development and deployment process.

Reference

  1. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
  2. https://github.com/dora-team/fourkeys
  3. Some of the industry's most commonly tracked incident metrics are MTBF (mean time between failure), MTTR (mean time to recover), MTTF (mean time to failure), and MTTA (mean time to acknowledge)