Terms Flashcards
A collection of Agile and DevOps terms from the Internet. (117 cards)
1
Q
Agent
A
A program installed on specific physical servers in order to handle the execution of various processes on that server.
2
Q
A/B Testing
A
A technique in which a new feature, or different variants of a feature, are made available to different sets of users and evaluated by comparing metrics and user behavior.
3
Q
Acceptance Testing
A
Typically high-level testing of the entire system carried out to determine whether the overall quality of both new and existing features is good enough for the system to go to production.
4
Q
Agent
A
An agent is a program installed on specific physical servers in order to handle the execution of various processes on that server.
5
Q
Agile
A
A precursor to Devops; Agile is a software development and, more broadly, business methodology that emphasizes:
- Short, iterative planning and development cycles
- to provide better control and predictability, and
- Support changing requirements as projects evolve.
6
Q
Agile Manifesto
A
The formal proclamation of values and principles to guide an iterative and people-centric approach to software development.
7
Q
Agile Organization
A
A flexible company capable of rapid response and adaptability to both expected and unexpected opportunities and threats.
8
Q
Agile Project Management
A
An iterative and incremental method of software design and development in which developers work closely with users using just enough information to start planning and execution.
9
Q
Agile software development
A
A software development methodology and philosophy, focused on user feedback, software quality, and the ability to respond quickly to changes and new product requirements.
10
Q
Antifragile
A
A term coined by professor Nassim Nicholas Taleb about a property that allows systems to increase in capability or performance as a result of stress, mistakes, faults or failures.
11
Q
Application Release Automation (ARA)
A
A practice of deploying software releases to various environments and their configurations with as little human interaction as possible.
12
Q
ARA
A
Application Release Automation
13
Q
Artifact
A
Any description of a process used to create a piece of software that can be referred to, including diagrams, user requirements, and UML models.
14
Q
Automation
A
The technology by which a process or procedure is performed without manual intervention. In DevOps, automation allows for the creation of real-time reports, integrating various tools used by different stakeholders, and workflows-integrating technology to bring tools together from different domains and break down the silos.
15
Q
Autonomy
A
The ability to make changes with the resources currently available, without the need to defer to something or someone higher up in the hierarchy.
16
Q
Behavior-Driven Development (BDD)
A
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.
* DSL: A domain-specific language is a computer language specialised to a particular application domain.
17
Q
Black Box Testing
A
A testing or quality assurance practice which assumes no knowledge of the inner workings of the system being tested, and which thus attempts to verify external rather than internal behavior or state.
18
Q
Bottleneck (Lean)
A
A step in a process that limits the total capacity of the process or system.
19
Q
Branching
A
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.
20
Q
Build Agent
A
A type of agent used in continuous integration that can be installed locally or remotely in relation to the continuous integration server. It sends and receives messages about handling software builds.
21
Q
Build Artifact
A
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.
22
Q
Build Artifact Repository
A
Centralized storage for all binaries used during build.
- Simplifies dependency management and build processes,
- Helps maintain security and consistency across teams,
- Helps make automated deployment practical and scalable.
23
Q
Build Automation
A
Tools or frameworks that allow source code to be automatically compiled into releasable binaries. Usually includes code-level unit testing to ensure individual pieces of code behave as expected.
24
Q
Cadence
A
The rhythm or sync of a DevOps value stream.
With cadence duration and predictability are the key points. Cadence is how long a Sprint, an iteration or a Program Increment lasts. Otherwise, their duration may vary.
25
CALMS Model
The essence of DevOps: Culture, Automation, Lean, Measurement, Sharing. It's a framework that can be used to assess an organization's readiness to adopt a DevOps process.
26
Canary Release
A go-live strategy in which a new application version is released to a small subset of production servers and heavily monitored to determine whether it behaves as expected. If everything seems stable, the new version is rolled out to the entire production environment.
27
Capacity Test
A test that is used to determine the maximum number of users a computer, server, or application can support just before failing.
28
ChatOps
It is about conversation driven development by bringing the tools into conversations. Robots are today members of your team to whom you can send a request and get an instant response.
ChatOps is a model where people, tools, process and automation are connected in a transparent flow. It also helps collaborate and control pipelines in one window.
29
Commit
A way to record the changes to a repository and add a log message to describe the changes that were made.
30
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.
31
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.
32
Configuration Management
A process for establishing and maintaining consistent settings of a system. These solutions also include SysAdmin tools for IT infrastructure automation (e.g. Chef, Puppet, etc.).
33
Constraint
A limitation or restriction on a system.
34
Constraints (Theory of)
A methodology for identifying the most important limiting factor that stands in the way of achieving a goal and then systematically improving that constraint until it is no longer the limiting factor.
35
Containerization
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.
36
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.
37
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.
38
Continuous integration (CI)
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
39
Continuous Quality
A 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.
40
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.
41
Culture
The whole of the ideas, values, beliefs, practices and behaviors that are shared by the employees in an organization. It is an attitude of shared responsibility in a DevOps environment.
42
Dark Launch
Dark launching is a process where software is gradually or stealthily released to consumers in order to get user feedback and test performance. Code is wrapped in a feature flag or feature toggle which is used to control who gets to see the new feature and when.
43
Definition of Done
In software development, a shared understanding of what it means for work to be complete.
44
Delivery Pipeline
A sequence of orchestrated, automated tasks implementing the software delivery process for a new application version. Each step in the pipeline is intended to increase the level of confidence in the new version to the point where a go/no-go decision can be made. A delivery pipeline can be considered the result of optimizing an organization's release process.
45
Deployment
A term that refers to the grouping of every activity that makes a program available for use and moving that program to the target environment. In DevOps environments, deployment is fully automated so users get updates as soon as they are written and tested.
46
Deployment pipeline
A deployment pipeline is an automated manifestation of your process for getting software from version control into the hands of your users.
47
Dev (from DevOps)
Individuals involved in software development activities.
48
DevOps
An IT organizational methodology where all teams in the organization, especially development teams and operations teams,
* Collaborate on both development **(Dev)** and deployment of software **(Ops)**,
* To increase software production agility and
* Achieve business goals.
49
DevOps Intelligence
Providing the intelligence and insight companies need to deliver software more efficiently, with less risk, and with better results.
50
DevSecOps
Automation of core security tasks by embedding security controls and processes into the DevOps workflow. The goal is to bring security into the process as early as possible in order to minimize vulnerabilities and risks.
51
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.
52
Exploratory Testing
A manual testing strategy where human testers have the freedom to test areas where they suspect issues could arise that automated testing won't catch.
53
Fail fast
A strategy in which you try something, it fails, feedback is delivered quickly, you adapt accordingly, and try again.
54
Feedback loop
Input on usability and user experience back to the developer.
55
Flow
How people or products move through a process. The DevOps First Way" is concerned with optimizing flow through systems."
56
Functional Testing
Functional testing is a quality assurance (QA) process and a *type of black-box testing* that bases its test cases on the **specifications** of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered.
Functional testing usually describes what the system does.
Functional testing tests a slice of functionality of the whole system.
**Functional testing** differs from system testing in that functional testing "**verifies** a program by checking it against ... design document(s) or specification(s)", while ***system testing***"***validate[s]*** a program by checking it against the published user or system requirements".
Functional testing has many types:
* Smoke testing
* Sanity testing
* Regression testing
* Usability testing
57
Gemba
Japanese word for "**the real place**". In business it often equates to "**where value is created**" and in lean manufacturing it means "the factory or shop floor".
In Lean Six Sigma (LSS) it is common to hear the phrase “**Going to Gemba**” (*meaning the real place where the work is being done*). This is also sometimes referred to as process mapping.
**DevOps:** Improving the whole and and not just focusing on the parts is a core tenant of both Lean Six Sigma (LSS) and the Theory of Constrains (TOC). Understanding bottlenecks and flow is an important part of understanding the “Value Stream”.
[Japanese Terms For DevOps Practictioners](https://itrevolution.com/japanese-words-for-devops-practitioners/)
58
Immutable infrastructure
An application service or hosting environment that, once set up, cannot be changed. If a DevOps team wishes to change a configuration on immutable infrastructure, the entire component must be re-initalized. While this may seem inefficient, the advantage of immutable infrastructure is that it makes environments more robust and reliable because inadvertent changes are impossible to introduce.
59
Impact Mapping
Impact mapping is a strategic planning technique. It prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.
60
Infrastructure-as-a-Service (IaaS)
A self-service computing, networking, and storage utility on-demand over a network.
61
Infrastructure-as-Code
An approach to infrastructure configuration that allows DevOps teams to use scripts in order to provision servers or hosting environments automatically. This saves them from having to set up infrastructure by hand, a time-consuming and mistake-prone process.
62
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.
63
Issue Tracking
A process that allows programmers and quality assurance personnel to track the flow of defects and new features from identification to resolution.
64
Iterations
A single development cycle, typically measured as one week or two weeks. Releases of applications or code. Faster iterations/releases results in faster feedback for the developer, increased quality, and speed to market.
65
Kaizen
Wikipedia describes Kaizen as an “improvement,” or “change for the better” which refers to _a philosophy or practices that focus on continuous improvement of processes_ in manufacturing, engineering, game development, and business management.
**Kaizen is a daily process, each day is better then the last**. Kaizen is also rooted in the idea that it is much more than just simple productivity improvement. When done right it’s about humanizing the workplace and eliminating overly hard work (muri). _Kaizen also teaches people how to apply the scientific method and learn how to spot and eliminate waste_.
Kaizen play a huge role in DevOps in that, like Lean, there is always a sense of improvement in the flow. Finding variation (bugs, performance issues) late in the flow and engineering them earlier in the process. Also, _Kaizen is also about continuously optimizing for the whole by alleviating bottlenecks_.
[Japanese Terms For DevOps Practictioners](https://itrevolution.com/japanese-words-for-devops-practitioners/)
66
Kanban
A visual method of controlling activity that pulls the flow of work through a process at a manageable pace.
67
Kanban Board
A Kanban tool that helps teams organize, visualize and manage work.
68
Kata
Literally means “**the form and order of doing things**.” The term is mostly popularized in the martial arts; however, outside of martial arts it refers to cultural conditioning. _Kata, in Japanese business, is the idea of doing things the “correct” way._ The art of bowing, exchanging name cards, the importance of apology, and the origin of the Japanese obsession for quality are all deeply rooted in their culture.
An organization culture can be characterized as it’s Kata through it’s consistent role modeling, teaching, and coaching. Mike Rother also popularized the notion of Kata and Lean in his book “Toyota Kata.” Toyota Kata is broken into two areas: Improvement Kata and Coaching Kata. **Improvement Kata** teaches the mastery of continuous improvement, adaptiveness, and innovation. **Coaching Kata** stresses the aspect of periodic observation and guidance. The theory is that if we are doing something that is difficult and we are not used to it we will default to the familiar without a coach. _In DevOps we think of Kata as the culture whereas Kaizen is the continuous improvement_. When an organization has optimized its Kaizen we can say that is their Kata.
[Japanese Terms For DevOps Practictioners](https://itrevolution.com/japanese-words-for-devops-practitioners/)
69
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.
70
Lean
A production philosophy that focuses on reducing waste and improving the flow of processes to improve customer value.
71
Lean IT
Applying the key ideas behind lean to the development and operation of IT products and services.
72
Mean Time Between Failures (MTBF)
Used to measure reliability of a system or component, calculated by averaging the time between system failures.
73
Mean Time to Recovery (MTTR)
The average time it takes a system or component to recover from a failure and return to production status.
74
Microservices
* Microservices is a software architecture design pattern,
* In which complex applications are composed of
* Small independent processes communicating with each other using language-agnostic APIs.
* These services are small,
* highly decoupled and
* focus on doing a small task.
75
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.
Because test suites are derived from models and not from source code, model-based testing is usually seen as one form of black-box testing.
76
Muda
Muda is waste. According to Taichi Ohno of Toyota _any activity that does not add value is considered waste_. The idea is to classify all activities into two categories: activities that add value and ones that don’t.
Eliminating waste in DevOps is a key principle. When we talk about the Aha to the Ka-ching we are _always looking for wasteful boundary handoffs_ as well as _things that impede our cycle time_ for customer delivery (i.e., the Ka-ching).
77
Mura
Mura means **inconsistency** or excess variation. When work is not standardized it can add waste in the form of wasted movement (e.g., not having clear process and procedures defined). _Mura can lead to quality issues_.
One of the core principles of Kanban as described by David Anderson is making process policies explicit. **Kanban is an excellent tool for reducing Mura**. One could argue that configuration management tools like Chef, Puppet and CFEngine control Mura by making processes for installing and configuring systems standardized. In many ways Lean is about eliminating waste (muda) and Six Sigma is about reducing variation (Mura). In DevOps we strive to reduce all of the 3 M’s (Muda, Mura, Muri).
[Japanese Terms For DevOps Practitioners](https://itrevolution.com/japanese-words-for-devops-practitioners/)
78
Muri
In Japanese the term literally means **overburden**, unreasonableness, or absurdity. Muri represents the activities where processes, people, or machines _are pushed beyond a reasonable limit_.
_An organization with Muri is more likely to have increased stress levels and reduced job satisfaction_. Organizations that are continually operating at capacity tend and have _less flexibility and longer lead times_. Many DevOps organizations try to combat Muri by building slack into their environment. Things like hack days, innovation days, and just percentage free time (e.g., Google 20% time) all help to reduce Muri.
[Japanese Terms For DevOps Practitioners](https://itrevolution.com/japanese-words-for-devops-practitioners/)
79
Non-functional Requirements (NFRs)
The specification of system qualities such as ease-of-use, clarity of design, latency, speed, ability to handle large numbers of users etc. that describe how easily or effectively a piece of functionality can be used, rather than simply whether it exists. These characteristics can also be addressed and improved using the Continuous Delivery feedback loop.
80
NoOps
A type of organization in which the management of systems on which applications run is either handled completely by an external party (such as a PaaS vendor) or fully automated. A NoOps organization aims to maintain little or no in-house operations capability or staff.
81
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.
82
Ops (from DevOps)
Individuals involved in the daily operational activities needed to deploy and manage systems and services.
83
Orchestration
The method to automate the management and deployment of your applications and containers.
84
Orchestration Pipeline
Tools or products that enable the various automated tasks that make up a Continuous Delivery pipeline to be invoked at the right time. They generally also record the state and output of each of those tasks and visualize the flow of features through the pipeline.
85
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.
86
Platform-as-a-Service (PaaS)
Provides languages, libraries, services, and tools that allow developers to build and deploy applications in the cloud without worrying about underlying OS-level infrastructure (or below).
87
Product Owner
A person or role responsible for the definition, prioritization and maintenance of the list of outstanding features and other work to be tackled by a development team. Product Owners are common in agile software development methodologies and often represent the business or customer organization. Product Owners need to play a more active, day-to-day role in the development process than their counterparts in more traditional software development processes.
88
Production
The final stage in a deployment pipeline where the software will be used by the intended audience.
89
Provisioning
The process of preparing new systems for users (in a Continuous Delivery scenario, typically development or test teams). The systems are generally virtualized and instantiated on demand. Configuration of the machines to install operating systems, middleware etc. is handled by automated system configuration management tools, which also verify that the desired configuration is maintained.
90
Regression Testing
Testing of the end-to-end system to verify that existing functionality has not been negatively impacted by changes to the application.
91
Release
One or more system changes that are built, tested and deployed together.
92
Release Coordination
The definition and execution of all the actions required to take a new feature or set of features from code check-in to go-live. In a Continuous Delivery environment, this is largely or entirely automated and carried out by the pipeline.
93
Release Management
Release Management is the process of managing software releases from development stage to the actual software release itself.
94
Release Orchestration
Release Orchestration is the use of tools like XL Release which manage software releases from the development stage to the actual software release itself.
95
Rollback
An automatic or manual operation that restores a database or program to a previously defined state.
96
Scrum
An Iterative, time-bound, and incremental Agile Framework for completing complex projects.
97
Self-Service Deployment
The action of automating deployment processes enough for developers to allow project managers or even clients to directly control deployments.
98
Serverless computing
A type of service that provides access to computing resources on demand, without requiring users to configure or manage an entire server environment. AWS Lambda is the most famous serverless computing product currently, but a number of competitors have arisen recently, including Azure Serverless Functions and IBM OpenWhisk.
99
Shift Left
The term 'shift left' refers to a practice in software development in which teams focus on quality, work on problem prevention instead of detection, and begin testing earlier than ever before. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises at the end of the development cycle-or, worse, in production.
100
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.
101
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.
102
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.
103
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.
104
Test-Driven Development (TDD)
A development practice in which small tests to verify the behavior of a piece of code are written before the code itself. The tests initially fail, and the aim of the developer(s) is then to add code to make them succeed.
105
The Three Ways
A set of principles developed by Gene Kim, award winning CTO, author, and researcher, to define what DevOps is really all about.
* First way: Speeding up the workflow, from business, through development, to operations, and the customer.
* Second way: Increase both the number of feedback loops in your flow and how fast you are getting the feedback.
* Third way: Develop and foster a culture where constant experimentation and learning is encouraged.
106
Time to Value
Measure of the time it takes for the business to realize value from a feature.
107
Toolchain
Use of an integrated set of task-specific tools to automate an end-to-end process. For example, automated code testing, release and deployment.
108
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.
109
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.
110
Value Stream Mapping
Lean tool that visualizes the flow of data, materials and work through a process with an emphasis on identifying and quantifying waste.
111
Velocity (Agile)
Measure of the quantity of work done in a pre-defined interval.
112
Virtual Machine (VM)
A software emulation of a physical computing resource that can be modified independent of the hardware attributes.
113
Virtualization
A systems management approach in which users and applications do not use physical machines, but simulated systems running on actual, real" hardware. Such "virtual machines" can be automatically created
114
Waste (Lean)
Anything that does not add value to a product. (See Muda, Muri, Mura.)
115
Waterfall (Software Development)
Linear and sequential approach to software design and development where progress is seen as flowing steadily downwards.
116
White Box Testing
A testing or quality assurance practice which is based on verifying the correct functioning of the internals of a system by examining its (internal) behavior and state as it runs.
117
Work in Progress (WIP)
Any work that has been started but has yet to be completed.
