40 DevOps Terms You Need to Know
40 DevOps Terms You Need to Know
This comprehensive resource will guide you through all the terms and concepts you need to know in the ever-changing world of DevOps.
Join the DZone community and get the full member experience.Join For Free
In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.
DevOps is a constantly evolving discipline. With new practices and processes created almost daily, it can be difficult to keep track of all the terminology. In an effort to help bring clarity to DevOps terms and practices, we compiled a list from our recent DevOps guides of what we feel are the most important DevOps terms and definitions that you should know.
Agent: A program installed on specific physical servers in order to handle the execution of various processes on that server.
Agile software development: A software development methodology and philosophy, focused on user feedback, software quality, and the ability to respond quickly to changes and new product requirements.
Artifact: Any description of a process used to create a piece of software that can be referred to, including diagrams, user requirements, and UML models.
Application release automation (ARA): The process of packaging and deploying software from development to production, where software is moved through different environments and releases are coordinated automatically.
Autonomy: The ability to make changes with the resources currently available, without the need to defer to something or someone higher up in the hierarchy.
Behavior-driven development (BDD): An evolution of test-driven development that focuses on collaboration between development and business stakeholders to define user stories that determine the development of the application using a human-readable DSL.
Branching: The duplication of an object under review in source control so that the same code can be modified by more than one developer in parallel.
Build artifact: The resulting application or object created by a build process. Typically this involves source code being compiled into a runtime artifact. In the Java ecosystem, this involves Java source code being compiled into a JAR or WAR file.
Capacity test: A test that is used to determine the maximum number of users a computer, server, or application can support just before failing.
Commit: A way to record the changes to a repository and add a log message to describe the changes that were made.
Complex-adaptive systems: Any system made of a collection of similar, smaller pieces that are dynamically connected and can change to adapt to changes for the benefit of a macrostructure.
Configuration drift: How software and hardware configurations become inconsistent with the master version due to manual and ad hoc changes (like hotfixes) that are not committed back to version control. Often a significant source of technical debt.
Containers: Resource isolation at the OS (rather than machine) level, usually (in UNIX-based systems) in user space. Isolated elements vary by containerization strategy and often include file system, disk quota, CPU and memory, I/O rate, root privileges, and network access. Much lighter-weight than machine-level virtualization and sufficient for many isolation requirement sets.
Continuous delivery (CD): A software engineering approach in which continuous integration, automated testing, and automated deployment capabilities allow software to be developed and deployed rapidly, reliably, and repeatedly with minimal human intervention.
Continuous deployment: A software development practice in which every code change goes through the entire pipeline and is put into production automatically, resulting in many production deployments every day. It does everything that Continuous Delivery does, but the process is fully automated, and there’s no human intervention at all.
Continuous integration (CI): A software development process where a branch of source code is rebuilt every time code is committed to the source control system. The process is often extended to include deployment, installation, and testing of applications in production environments.
Continuous quality: The principle that preaches the continuous quest for quality across the entire SDLC, starting from requirements definition, code development, testing, and operations. Another key area of focus for Continuous Quality is the application code pipeline orchestration. There are many opportunities to negatively impact the quality of an application when code is being manually moved across environments.
Continuous testing: The process of executing unattended automated tests as part of the software delivery pipeline across all environments to obtain immediate feedback on the quality of a code build.
Deployment pipeline: A deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users.
DevOps: An IT organizational methodology where all teams in the organization, especially development teams and operations teams, collaborate on both development and deployment of software to increase software production agility and achieve business goals.
DevSecOps: Integrating security as an integral part of the DevOps methodology.
Event-driven architecture: A software architecture pattern where events or messages are produced by the system, and the system is built to react, consume, and detect other events.
Fail fast: A strategy in which you try something, it fails, feedback is delivered quickly, you adapt accordingly, and try again.
Feedback loop: Input on usability and user experience back to the developer.
Integration testing: Testing that occurs after unit testing, but before validation testing, where individual software components are combined and tested as a single group to ensure they work as a whole.
Iterations: Releases of applications or code. Faster iterations/releases results in faster feedback for the developer, increased quality, and speed to market.
Lead time: The time it takes to move work in progress (WIP) to a finished state in a manufacturing plant. In software development, this is represented by moving code changes to production.
Microservices architecture: The practice of developing software as an interconnected system of several independent, modular services that communicate with each other.
Model-based testing: A software testing technique in which the test cases are derived from a model that describes the functional aspects of the System Under Test (SUT). Visual models can be used to represent the desired behavior of a SUT, or to represent testing strategies and a test environment. From that model manual tests, test data, and automated tests can be generated automatically.
One-stop shop/out-of-the-box tools: Tools that provide a set of functionalities that works immediately after installation with hardly any configuration or modification needs. When applied to the software delivery, a one-stop shop solution allows quick setup of a deployment pipeline.
Orchestration: The method to automate the management and deployment of your applications and containers.
Pair-programming: A software development practice where two developers work on a feature, rather than one, so that both developers can review each others’ code as it’s being written in order to improve code quality.
Production: The final stage in a deployment pipeline where the software will be used by the intended audience.
Shift left: Introducing automated testing into the SDLC from inception.
Source control: A system for storing, tracking, and managing changes to software. This is commonly done through a process of creating branches (copies for safely creating new features) off of the stable master version of the software and then merging stable feature branches back into the master version. This is also known as version control or revision control.
Staging environment: Used to test the newer version of your software before it’s moved to live production. Staging is meant to replicate as much of your live production environment as possible, giving you the best chance to catch any bugs before you release your software.
Technical debt: A concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.
Test Automation: The use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.
Unit testing: A testing strategy in which the smallest unit of testable code is isolated from the rest of the software and tested to determine if it functions properly.
User acceptance test: The final phase of software testing where clients and end users determine whether the program will work for the end-user in real world scenarios. This stage is also known as beta testing.
Are there any DevOps terms that we missed? Let us know and we'll add them to the list!
Opinions expressed by DZone contributors are their own.