This page is dedicated to the general lingo, jargon, idioms, slang, vocabulary, and buzzwords for DevOps along with definitions.

A

Agent

A software agent is designed to automate certain tasks related to the development and operation of software systems. These tasks may include building and testing code, deploying code to production environments, monitoring the health and performance of systems, and performing other tasks as needed to ensure the smooth operation and development of software systems.

Agents are typically designed to work in concert with other tools and processes within the DevOps ecosystem, such as continuous integration and delivery (CI/CD) pipelines, configuration management systems, and monitoring and alerting tools. They may also be integrated with collaboration and communication tools, such as chat or issue tracking systems, to facilitate communication and coordination between team members.

Overall, the goal of a DevOps agent is to improve the efficiency, reliability, and agility of software development and operations teams by automating a range of tasks and processes, and by providing a centralized point of control for managing and coordinating the various tools and processes within the DevOps ecosystem.

Agentless

In the context of DevOps, "agentless" typically refers to the use of tools or technologies that do not require the installation of a software agent on the target system in order to perform certain tasks or functions.

For example, some configuration management tools, such as Ansible, allow users to manage and configure systems remotely without the need to install a dedicated agent on the target system. Similarly, some monitoring and alerting tools use protocols such as SNMP (Simple Network Management Protocol) to collect data and monitor the health and performance of systems without the need for a dedicated agent.

The use of agentless tools and technologies can have a number of benefits in the DevOps context, including:

  1. Simplicity: Agentless tools and technologies can be simpler to use and set up than those that require the installation of a dedicated agent.
  2. Portability: Because agentless tools and technologies do not require the installation of a software agent on the target system, they can be more portable and easier to use in environments where it is difficult or impractical to install software.
  3. Security: In some cases, the use of agentless tools and technologies may be more secure, as they do not introduce additional components onto the target system that could potentially be exploited by attackers.

Overall, the choice between using agent-based or agentless tools and technologies will depend on the specific needs and requirements of a given DevOps environment, and may involve trade-offs in terms of simplicity, portability, and security.

Agile Software Development

Agile software development is a set of values, principles, and practices that aim to improve the speed and flexibility of software development by focusing on rapid iteration and continuous delivery of working software. Agile development approaches are designed to be adaptable and responsive to change, and to enable teams to respond quickly to new requirements or changes in the business environment.

In the context of DevOps, agile software development practices can be used to help teams build, test, and deploy software in a rapid and continuous manner. This can involve using tools and processes such as continuous integration and delivery (CI/CD) pipelines, automated testing, and deployment automation to enable teams to deliver software updates and new features on a frequent and predictable basis.

Some of the key principles of agile software development that are relevant to DevOps include:

  1. Collaboration: Agile development emphasizes the importance of close collaboration between development and operations teams, as well as between developers, testers, and other stakeholders.
  2. Adaptability: Agile development approaches are designed to be adaptable and responsive to change, enabling teams to pivot quickly in response to new requirements or changes in the business environment.
  3. Continuous improvement: Agile development emphasizes the importance of continuous learning and improvement, and encourages teams to regularly review and assess their processes and practices to identify opportunities for improvement.

This is a version of software development that is not based purely in a linear flow of work.  Traditional software development will follow a Waterfall delivery methodology.  Agile software development will follow a more prescriptive delivery flow like SAFe.

Application Release Automation (ARA)

Application-release automation (ARA) is a process or set of tools and practices that aim to automate and streamline the process of releasing software updates and new features to production environments. ARA typically involves automating the various tasks and processes involved in building, testing, and deploying code, including tasks such as building and testing code, promoting code through different environments, and rolling out code to production environments.

In the context of DevOps, ARA can be a critical component of the overall software development and deployment process, helping teams to reduce the time and effort required to release updates and new features, and improving the speed and reliability of software deployments.

Some of the key features and benefits of ARA in the DevOps context include:

  1. Speed: ARA can help teams to reduce the time and effort required to release software updates and new features, enabling teams to deliver software more quickly and respond more quickly to changing business needs.
  2. Reliability: ARA can help teams to ensure that software releases are consistent, repeatable, and reliable, reducing the risk of errors or disruptions during the release process.
  3. Visibility: ARA typically provides a central point of control and visibility for managing and coordinating the release process, helping teams to understand the status of releases and identify any issues or bottlenecks in the process.
  4. Integration: ARA can be integrated with other tools and processes within the DevOps ecosystem, such as continuous integration and delivery (CI/CD) pipelines and monitoring and alerting tools, to provide a more comprehensive view of the release process and to facilitate collaboration and coordination between teams.

Artifact

In the context of DevOps, an artifact is a file or set of files that is produced as part of the software development and deployment process. Artifacts may include things such as compiled code, configuration files, scripts, test results, and other types of files that are used or generated as part of the development and deployment process.

Artifacts are typically stored in a central repository or artifact store, and may be shared or transferred between different tools and processes within the DevOps ecosystem. For example, artifacts may be generated as part of a continuous integration and delivery (CI/CD) pipeline, and then passed on to other tools or processes for further testing, deployment, or release.

Artifacts can play a critical role in the DevOps process, as they provide a record of the various stages of the development and deployment process, and can be used to trace the history and provenance of software releases. They can also help teams to automate and streamline the process of building, testing, and releasing software, by providing a central point of access to the various files and assets needed to build and deploy software.

Automated Deployment

Automated deployment is the use of tools and processes to automate the process of releasing code and other artifacts to production environments. Automated deployment can help teams to reduce the time and effort required to deploy code, and to improve the reliability and speed of deployments.

In the context of DevOps, automated deployment is typically part of a continuous integration and delivery (CI/CD) pipeline, which automates the process of building, testing, and deploying code. The CI/CD pipeline may include a number of different stages, such as building and testing code, promoting code through different environments, and rolling out code to production environments.

Automated deployment can involve a range of tasks and processes, including:

  1. Building and packaging code and other artifacts: This may involve tasks such as compiling code, creating deployment packages, and generating any necessary configuration files or scripts.
  2. Testing code: This may involve running automated tests to ensure that code is functional and meets quality standards, and may include tasks such as unit testing, integration testing, and acceptance testing.
  3. Promoting code through different environments: This may involve moving code from one environment to another, such as from a development environment to a staging environment, or from staging to production.
  4. Rolling out code to production environments: This may involve tasks such as deploying code to production servers, updating configuration files, and restarting services as necessary.

Automated Provisioning

Automated provisioning is the use of tools and processes to automate the process of setting up and configuring infrastructure in a consistent and repeatable manner. Automated provisioning can help teams to reduce the time and effort required to set up and configure systems, and to improve the consistency and reliability of deployments.

In the context of DevOps, automated provisioning is typically achieved through the use of configuration management tools, such as Ansible, Puppet, or Chef. These tools allow teams to define and manage the configuration of systems using a declarative configuration language, and to automate the process of provisioning and configuring infrastructure, including tasks such as installing and configuring software, setting up and configuring servers and other infrastructure components, and managing and updating configuration files.

Automated provisioning can be used in a range of contexts, including:

  1. Setting up and configuring new systems: Automated provisioning can help teams to quickly and consistently set up and configure new systems, reducing the time and effort required to get systems up and running.
  2. Managing and updating existing systems: Automated provisioning can help teams to manage and update the configuration of existing systems in a consistent and repeatable manner, ensuring that systems remain up-to-date and compliant with company policies and best practices.
  3. Provisioning and configuring infrastructure in cloud environments: Automated provisioning can be particularly useful for setting up and configuring infrastructure in cloud environments, where the ability to quickly and consistently provision and configure resources can be a key advantage.

Automated Testing

Automated testing is the use of tools and processes to automate the testing of software, in order to reduce the time and effort required to test code, and to improve the reliability and coverage of testing.

In the context of DevOps, automated testing is a key component of the overall software development and deployment process, and is typically integrated with other tools and processes such as continuous integration and delivery (CI/CD) pipelines. Automated testing can involve a range of different types of tests, including unit tests, integration tests, acceptance tests, and performance tests.

Some of the key benefits of automated testing in the DevOps context include:

  1. Speed: Automated testing can significantly reduce the time and effort required to test code, enabling teams to deliver software updates and new features more quickly.
  2. Reliability: Automated tests are typically more consistent and reliable than manual testing, as they do not rely on human intervention and are less prone to errors.
  3. Coverage: Automated testing can help teams to achieve a higher level of test coverage, by running tests more frequently and on a wider range of inputs and configurations.
  4. Efficiency: Automated testing can help teams to more efficiently allocate testing resources, by allowing teams to focus on more complex or value-added tasks, rather than on routine testing tasks.

Autonomy

In the context of DevOps, autonomy refers to the use of tools and processes to automate various tasks and processes within the software development and operations lifecycle. This can include things such as automating the build, test, and deployment of code, automating the provisioning and configuration of infrastructure, and automating the monitoring and management of systems.

The use of autonomy in DevOps can help teams to improve the efficiency, reliability, and speed of software development and operations, by reducing the need for manual intervention and enabling teams to focus on higher-value tasks.

There are a number of different approaches to achieving autonomy in DevOps, including the use of:

  1. Continuous integration and delivery (CI/CD) pipelines: These pipelines automate the process of building, testing, and deploying code, enabling teams to deliver software updates and new features on a frequent and predictable basis.
  2. Configuration management tools: These tools automate the process of provisioning and configuring infrastructure, helping teams to quickly and consistently deploy and manage systems.
  3. Monitoring and alerting tools: These tools automate the process of monitoring systems and alerting teams to issues or problems, enabling teams to proactively identify and resolve issues before they impact users.

The primary goal of autonomy in DevOps is to enable teams to work more efficiently and effectively, by automating tasks and processes that are repetitive or time-consuming, and by freeing up team members to focus on more complex or value-added tasks.

Availability

In the context of DevOps, availability refers to the ability of a system or service to be accessible and functioning as expected. Availability is typically measured as a percentage of uptime, and is an important consideration for any system or service that is critical to the operation of a business or organization.

In the DevOps context, ensuring availability typically involves a range of practices and tools, including:

  1. Monitoring: Monitoring systems and services can help teams to identify and resolve issues or problems that may impact availability.
  2. Alerting: Setting up alerts can help teams to proactively identify and respond to issues or problems that may impact availability.
  3. Redundancy and failover: Designing systems and services with redundancy and failover capabilities can help to improve availability by enabling systems to continue operating in the event of an outage or other problem.
  4. Disaster recovery: Planning and preparing for the recovery of systems and services in the event of a disaster or other catastrophic event can help to improve availability by enabling teams to quickly and effectively recover from disruptions.

B

Behavior-Driven Development (BDD)

Behavior-Driven Development (BDD) is a method of development where tests are written in a more natural language syntax instead of purely code-based tests.  BDD is an evolution from Test-Driven Development (TDD) where failing tests are written before code.  Code is then written to satisfy the tests.

Blue/Green Deployment

Blue/green deployments are a DevOps strategy that allow teams to safely and efficiently release new software updates to production. The approach involves running two identical production environments in parallel, with one designated as the "green" environment and the other as the "blue" environment.

Before a new release, the latest version of the software is deployed to the green environment and thoroughly tested. Once the testing is complete and the new version is deemed stable, traffic to the production environment is redirected from the blue environment to the green environment. This allows for a quick and seamless transition to the new version, minimizing downtime and reducing the risk of a negative impact on users.

Branching

Branching is a key concept in DevOps that refers to the practice of creating separate versions of code within a version control system, such as Git. This allows multiple developers to work on the same codebase simultaneously without interfering with each other's work.

In a typical DevOps workflow, a main or "main" branch is created, which serves as the stable and production-ready version of the code. Developers then create separate branches from the main branch for each new feature or bug fix they are working on. These individual branches can be tested and reviewed independently, and when they are ready, they can be merged back into the main branch.

Branching allows teams to work efficiently and collaboratively, while also providing a clear separation between the stable production version of the code and the ongoing development work. This helps to minimize the risk of introducing bugs into the production environment and makes it easier to revert back to a previous version of the code if necessary.

Build Agent

A build agent is an important component in a DevOps pipeline that helps to automate the software build process. A build agent acts as a bridge between the build server and the development environment, allowing the build server to offload the resource-intensive task of building and compiling code to the build agent.

A build agent is essentially a software service that runs on a physical or virtual machine, and is responsible for executing build tasks on behalf of the build server. It holds all of the dependencies that are required for a build to complete, including programming languages like Java, NodeJS, PHP, and any other tools and libraries that are required for building and testing the software.

The build agent acts as an isolated environment that can run builds independent of the build server and the development environment. This makes it possible to run builds on multiple build agents in parallel, which can greatly speed up the build process and reduce the time required to release new software updates.

Overall, build agents play a critical role in DevOps by enabling teams to automate the build process and quickly produce high-quality software artifacts that are ready for deployment to production.

Build Artifact Repository

A Build Artifact Repository, also known as a Binary Repository, is a central storage location where build artifacts and packages are stored, versioned, and managed. It is a crucial component of a DevOps pipeline that provides a centralized and secure place to store the software components that are produced during the build process.

Build artifacts are the outputs of the build process, such as executables, libraries, and Docker images, and they represent the various stages of the software development lifecycle. A Build Artifact Repository provides a centralized and organized way to manage these artifacts, and ensures that all members of a development team have access to the latest version of the software.

The use of a Build Artifact Repository has several benefits in DevOps. It provides a single source of truth for the software components that are used in the build process, which helps to eliminate the risk of using outdated or incorrect components. It also provides versioning and history tracking, making it easy to revert back to a previous version of the software if necessary. Additionally, it allows for the reuse of common components across multiple builds, reducing build times and improving build consistency.

AWS CodeArtifact, as mentioned in the definition, is one example of a Build Artifact Repository. Other popular tools in this category include JFrog Artifactory, Nexus Repository, and Apache Archiva These tools allow teams to manage their build artifacts in a secure, scalable, and organized manner, which helps to improve the overall efficiency and quality of the software development lifecycle.

C

Canary Release

A canary release is a deployment methodology where a small percentage of servers are chosen to run new code releases.  If those new servers are running as expected, more servers are chosen to run new code.  The eventual state is to either have all servers running new code or to detect errors and roll the release back to a previous state.  This is named after the saying "a canary in the coal mine".

Capacity Management

Capacity management is the process of planning, designing, and controlling the use of resources in a DevOps environment. The goal of capacity management is to ensure that the necessary resources are available to meet the demand of the systems and applications that are deployed in a DevOps pipeline.

In DevOps, capacity management is a critical component of the overall IT infrastructure management process. It involves the identification, analysis, and prediction of the resource requirements of the systems and applications that are being developed and deployed. This helps to ensure that the necessary resources, such as computing power, memory, storage, and network bandwidth, are available to meet the demand of the system at any given time.

Capacity management also involves monitoring the usage of resources in real-time and making adjustments as needed to ensure that the systems are performing optimally. This may involve adding or removing resources as demand changes, or making changes to the configuration of the systems to improve performance.

Overall, capacity management plays a crucial role in DevOps by helping teams to ensure that the necessary resources are available to meet the demand of the systems and applications that are being deployed. By continuously monitoring and adjusting the use of resources, teams can ensure that their systems are performing optimally, which helps to improve the overall efficiency and reliability of the software development and deployment process.

Capacity Test

A capacity test is a type of performance test that is used in DevOps to determine the maximum load that a system can handle before it becomes unavailable or starts to degrade in performance. The goal of a capacity test is to identify the limitations of a system and determine the resources (such as CPU, memory, and network bandwidth) that need to be increased in order to handle higher loads.

Capacity tests are typically performed before a new release of a software application is deployed to production, or when changes are made to the infrastructure that supports the application. The test is designed to simulate the maximum expected load on the system, and the results are used to identify potential bottlenecks and performance issues.

In DevOps, capacity testing is an important step in the continuous delivery and deployment process. By performing capacity tests before deploying a new release, teams can ensure that the system will perform well under real-world conditions and that users will have a positive experience. Additionally, capacity testing can help to prevent system failures and downtime, which can result in lost revenue and damage to the reputation of the company.

Overall, capacity testing is a critical component of DevOps that helps teams to validate the performance and scalability of a system before it is deployed to production. By performing regular capacity tests, teams can continuously monitor and optimize the performance of their systems, ensuring that they are able to handle increasing loads as the user base grows.

Commit

Create a checkpoint for code at a point in time.  A commit represents a unit of work being completed.

Configuration Management

Early IT operations would make manual changes to systems that were hard to track and would lead to system outages if not completed properly.  Configuration managed mains to solve this by ensuring that all changes are captured in code in a repository.  Subsequently, those changes are pushed down CI/CD pipelines along with application code keeping infrastructure and applications in sync.

Container Image

A container image is a zip file of a filesystem.  When run, a container image is unzipped and resources are assigned from a CGroup to start the image.

Containerization

Containerization is the act of taking an application that runs on bare metal and transforming it to run inside a container.

Containers

Containers are slices of a Linux machine's resources via CGroups.  This allows for more fine-grained slicing and optimization of resources in an environment.

Continuous Delivery

Continuous delivery is the act of building workflows, processes, and technology that allow for rapid delivery of valuable technology to customers with the lowest delay possible.

Continuous Deployment

Continuous deployment is the act of deploying technology changes to production many times per day.

Continuous Integration

Continuous integration is the act of pulling together code changes, automated testing, and infrastructure configuration management into a single artifact and running automated testing to ensure the quality of the newly created deliverable.  The goal of Continuous integration is to ensure that continuous delivery is fed with quality products that can be moved into production rapidly.

Continuous Quality

Continuous quality is the act of consistent review of work products (code changes) against quality standards.  This can be done manually through code reviews, or automatically via tools.

Continuous Testing

Continuous testing is the idea that every change should be run through testing before being deployed to production.  This can be done manually or via automation tools.  Strategies such as TDD or BDD were developed to rationalize continuous testing as a methodology that can be communicated between different parties.

D

Dark Launch

A dark launch is a release of new products or features without any promotion or advertising campaign.  This allows teams to build telemetry, understand quality and scalability issues, and introduce changes that help the long-term health of products as promotion and advertising campaigns ramp up.

Deployment

The act of changing a version of running code on a system.  This can be either application or configuration based.

Deployment Pipeline

A series of steps are taken to ensure that a new consistent state can be achieved in an environment.

DevOps

DevOps is the merging of Development and Operations into a singular team.  This ensures that a global perspective is taken by a team and focus is changed from pure feature development into a perspective of perpetual quality.

DevSecOps

DevSecOps is the practice of integrating security as code into DevOps practices.

Disaster Recovery

The act of recovering systems in the event that primary production systems become unusable.  This is usually tied with a secondary warm production environment that is flipped over to when production is un an unusable state.

E

Event-Driven Architecture

An event-driven architecture is a concept of triggering events in a publisher-subscriber relationship to effect change in a system.  More traditional architectures would rely on information being inserted into a database with downstream processes polling tables for those updates.  In an event-driven architecture, changes would be put on a queue by publishers and subscribers would act on those events in a near real-time fashion.

Exploratory Testing

Developing tests against a system that is well outside of the intended scope of that system.

F

Fail Fast

Big bang releases don't work.  Fail Fast is a method of taking changes and shrinking them down to bite-sized chunks where failing can be done in an extremely low-risk way.

I

Infrastructure-as-a-Service (IaaS)

Infrastructure-as-a-Service (IaaS) is when you are able to utilize virtualized infrastructure resources over the internet remotely.  AWS and Azure are prime examples of IaaS.

Integration Testing

Integration testing is the act of pulling together code changes, automated testing, and infrastructure configuration management into a single artifact and running automated testing to ensure the quality of the newly created deliverable.

Issue Tracking

Let's face it, defects are going to happen.  Defects are logged as issues into tools like Jira to accomplish tracking those issues and where they are in the process of getting fixed.

L

Lead Time

Lead time is the amount of time it will take between when work is planned and the work is ready for use in production.

M

Mean Time Between Failures (MTBF)

On average, how much time passes between failures in a system?

Mean Time to Recovery (MTTR)

On average, how much time does it take to recover from failures in a system?

Microservices

In the industry, you will hear the terms monolithic and microservices.  A monolithic architecture composes all application functionality into a single application.  Microservices deploy smaller functional services that are responsible for a single data domain.  When data in the domain changes, microservices will utilize an Event Driven Architecture to notify downstream subscribers of those changes.

O

Orchestration

Events in a system, like deployments, need to be coordinated between systems to prevent impact to end users.  An example of orchestration would be blue/green deployments.  Automation will need to orchestrate which servers are in and out of a load balancer and react once automated validation steps are complete.

P

Platform-as-a-Service (PaaS)

Services being run in the cloud that can be consumed by others.

Production

The environment where code is run by a business to get value out of technology being developed.

R

Redirect

Pointing an old resource at a new resource.

Regression Testing

Ensuring changes to a system do not introduce new bugs in previously stable parts of a system.

Release Orchestration

Coordinating activities of a release in technology.  Usually, a release is not as simple as bumping a code version, there may be lots of additional steps like database updates, redirect changes, certificate updates, etc. and all of those events are handled through automated release orchestration.

Rollback

Reverting a running code version back to a previous state.

S

Self-Service Deployment

A self-service deployment is a deployment that does not need anything special (knowledge, skill, technology) to be run by an average user.  No handoff needs to happen in order to perform a self-service deployment.

Single Point of Truth

The system is the definitive answer to any question you might have about your technology.

Source Control

A system like GitHub where code can be pushed.  Source control accumulates all code changes in a central place where build systems can pull that code to create artifacts and kick off CI/CD.

Staging Environment

An environment that is not production where code can be run and evaluated.

T

Technical Debt

Aging technology that persistently causes issues or increases susceptibility to security events.

Test Automation

Replacing human testing with computerized testing of the technology.  Humans still write tests, but humans are not relied upon to qualify code as "ready for production".

U

Unit Testing

The act of writing tests for specific functions of an application to ensure those functions perform as designed.

User Acceptance Test

End users test a solution to ensure that it meets requirements.

V

Virtual Machine (VM)

Programmatically chopping up server resources so that many virtual servers can be run on top of a single physical server.