Development Operations, or DevOps, is a cycle for software creation focused on the continuous improvement and delivery of software.
Traditional views of software development measure projects in terms of months or years, with fixes and updates seen as problems that raise costs, and so should be avoided.
Somewhere, a developer has to respond to a new feature being required, a bug arising, or a security breach being detected by changing the underlying code. With each of these changes, it is important to avoid creating new problems and ensure that every other team of developers working on different updates or fixes for the same software is using the latest code.
Longer development cycles were not an issue when software was distributed via diskettes and other physical media. Even when internet connectivity was expanding, the mindset of updating software involved intentionally downloading an update and manually running the installer. As mobile technology has developed over the last 5-10 years, a new mental model of constantly up-to-date apps emerged. As a result, DevOps' development cycles are sometimes measured in hours or days and can involve several teams working on different updates and fixes for the same software simultaneously.
DevOps aims to solve the management of those moving pieces and automate many of those elements.
All DevOps stakeholders understand one another's basic roles and share a baseline level of Digital Fluency. Due to the way this differs from most organizational structures, it is essential to dynamically align incentives, ensure resources are available, and build strong lines of communication.
DevOps shares some elements of the agile and lean models of business development, which are focused on velocity over perfection.
DevOps aims to:
Before the DevOps approach was widely implemented, both established organizations and startups struggled to update and upgrade software at scale.
DevOps is a reorganized development process that uses several key steps, well-defined responsibilities, and effective communication to ensure continuous improvement. Using these principles grants some autonomy and creativity inside a larger lifecycle focused on alignment and standardization.
DevOps is a continuous cycle, often depicted as an infinity symbol, where the 'final' stage connects to the 'first', to emphasize the continuing nature of the process.
The stages in DevOps are:
There are variations on this approach, sometimes naming 'release' and 'deploy' continuous integration & continuous deployment (CI/CD). At its core, the cycle is intended to manage a series of handoffs between different responsibilities in a more fluid, iterative way.
The 'Seasons of Innovation' mindset refers to the overall maturity and confidence level in an offering or a business model.
The DevOps cycle repeats as products move through each 'season of innovation,' but some DevOps stages are emphasized more than others in different seasons.
In the winter, the DevOps cycle's 'Monitor' mode might show a decline in users from a current offering or indicate a level of interest in something not yet offered in a product.
In the spring, the 'Plan' mode kicks in.
In the summer, the 'Code & Assemble,'' 'Build,' 'Release,' and 'Deploy' phases are key.
And in the fall, the 'Operate' and 'Monitor' modes are vital.
Traditional software development came from existing institutions, heavily-optimized software companies (like Microsoft in the 1990s), or one-off projects. Applying the same truisms (and linearity) of the industrial age seemed logical to software development in those contexts.
As a result, planning rigidly preceded design, followed by coding, testing, and release. When represented as a timeline of phases where each one flowed into the next, progress looked like a waterfall—hence the name.
But in this model, when a delay or mistake from one phase occurred, all subsequent phases were affected. This cascade of delays and failures meant that software projects took a long time or were never delivered.
Software that is developed to stand alone and not interact with the internet or any other apps probably doesn't need to change for many years at a time. For example, an app that converts imperial measurements to metric, or a coffee shop's cash register, doesn't connect to anything outside of itself. So no further development is needed as long as everything—the operating system, the hardware, etc.—stays the same.
When software is interoperable with other apps, operating systems, and the internet, there are a lot of variables that the original software developer cannot predict, so updates, fixes, etc., are an expected part of the process.
This is part of what necessitated the shift to the DevOps suite of mindsets, toolsets, and practices. With the constant cycle of updates and multiple teams creating different fixes simultaneously, it became essential that everyone working on a piece of software is working on the most up-to-date version.
Part of DevOps is having software for software.
This is the difference between waterfall and agile approaches to software development.
.jpg)
In the late 90s, software developers struggled with competing goals in their projects, such as a desire to ship working software quickly vs. creating a perfect product.
The agile software movement was born from those dilemmas, and in 2001 the Manifesto for Agile Software Development was published.
In their manifesto, they wrote priorities for their values:
"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan."
It is an excellent example of how concise a set of principles can be while giving enough guidance to be useful and still leaving plenty of room for interpretation and innovation.
By codifying this level of flexibility while still setting out fundamentals, a highly distributed Agile community could collaborate on development methodologies and create a distinct culture of innovation that is still going strong decades later.
Open-source models provided many challenges and lessons to the software development world. Open-source software is developed by many different parties for various reasons and often serves as a 'common core' function for other software (such as PHP, which powers many website servers, and Python, a programming language used by data scientists).
Open-source developers have to collaborate around common values and a shared purpose because they don't have authority over each other. Similarly, varying departments inside large organizations need to work with each other despite competing objectives and a lack of clarity over who has 'authority.'
The desire to bring open-source development principles into organizations and apply open-source software principles to the development of proprietary code is sometimes referred to as 'innersourcing,'.
Within a digital factory, there are several methodologies related to DevOps. It's helpful to know how they connect and why each is valuable.
Define what is by listening to people, and then imagine new possibilities.
Test ideas as quickly and inexpensively as possible to learn what the right thing is.
Lean is the framework for testing beliefs and learning the way to the proper outcomes.
Agile is how to adapt the software to changing conditions.
DevOps is how to reliably, securely, and quickly deliver software.
In other words, everyone involved—across a large number of different teams and departments—needs a base-level understanding of the development lifecycle and digital business ecosystem. All of the people who are accountable for successful digital initiatives need to participate at some level in DevOps, even if just providing input at the beginning of the process.
This means that software developers, IT operators, and security teams all need to also understand the business models and needs that are associated with a particular initiative, as well as the user's wants and expectations.
Velocity is a crucial measure of a company's DevOps success. In this context, velocity refers to how quickly software can respond to the developing needs of users, changing security environments, or business updates. Velocity also reflects a team's ability to communicate and the efficiency of the systems already in place.
Another measure of the overall success of a digital factory (and DevOps, specifically) is how much it costs per given deployment or product to make and release updates and otherwise maintain it. In traditional software development, everything is seen as one project, and it's easy for there to be significant cost overruns, which can lead to resistance to adding new features or otherwise developing the software.
DevOps promises to lower the per-change cost of software development for businesses in the long term. However, in the short term, it may be just as expensive as other approaches to software development or even more expensive during the setup period due to the large number of people involved and systems being integrated. This is why digital champions need to set clear directionality for the company through a digital narrative and other elements of strategy—it provides 'air cover' for technologists who are making a case for investing in foundational technologies and teams.
DevOps success is measured in many ways, depending on the type of DevOps team and their objectives. However, all effective teams pay attention to a couple of key metrics:
These are sometimes referred to as DORA metrics, after Google's DevOps Research & Assessment team, who first popularized them. At each DevOps stage, these and additional metrics will be used by teams to measure their efficacy.
Tools Notice:
Specific tools may show the company's tagline for their offering or our paraphrased version for clarity. Specific tools listed may link to their own website, which is outside our control. Causeit, Inc., the creator of this Digital Fluency Guide, does not receive any sponsorship money or affiliate revenue from any listed company. However, members of the Causeit team may own stock in publicly-traded companies shown here, either directly or via ETFs/mutual funds/other assets. Causeit also does not represent any of these companies or make statements on their behalf. The referenced companies/tools are shown primarily as examples of commonly discussed solutions in the marketplace and development communities and are not rigorously ranked or scientifically selected.
The Plan stage of the DevOps cycle begins when a team has declared its intention to release software and ends when the focus shifts to coding and assembly.
At this point, the focus is on mapping customer or user needs and solving them with software, centering user needs in the decision-making process.
This stage can include a variety of thinking approaches and styles, and it is helpful to set explicit expectations about which forms of thinking are needed. For example, 'divergent thinking' about new possibilities might be very helpful in the early stages of a product, but 'convergent thinking' may be more relevant to updating plans for an existing product or service.
Design Thinking is a critical element, allowing the team to gather as much information as possible from the right places and then ask, "Are we thinking about this in the right way?" before committing time and energy to coding.
To borrow an aphorism, this is the ax-sharpening phase of cutting down a tree.
Key activities in this stage begin with identifying needs for the application or initiative from various groups, including end-users (in the form of persona models), business stakeholders, and technology stakeholders. These needs are then mapped to objectives and key results in various forms, including:
Various team members must be identified in key roles, with specific and well-defined responsibilities. Due to the organizational siloing of departments and resources, many businesses find this a challenging task. Good communication and principles of networked leadership are important throughout DevOps, but especially in this stage.
Creating and adjusting budgets for time, money, and other resources are necessary in the plan stage. Participants also need to consider data ethics, cybersecurity, and legal & compliance strategies.
After this, a backlog—a list of development needs—is created, broken down into smaller batches, and sequenced according to priority. These are then grouped with other discussions, tests, etc., into sets of work, known as 'sprints.'
At this point, it is also helpful to identify existing technology resources (applications, code libraries, APIs/SDKs, prior custom code, open-source resources, and off-the-shelf software) that can meet the plan's requirements and be integrated without having to create them from scratch. This leaves the writing of custom code only for any remaining unmet needs.
Successful tech firms add time for experimentation, creativity, divergent thinking, and other work that doesn't seem immediately productive during the planning phase.
Abbreviating the planning stage will cause a reduction in software quality because it does not leave time to ask fundamental questions about the feasibility, desirability, and viability of features, product strategy, and business models.
The Plan phase falls into the Winter season of innovation. In that metaphor, this may be seen as considering not just which crops to grow but also the layout of the fields, the techniques used to plant and water the crops, and all other aspects of the process that might otherwise go unexamined in favor of 'business as usual.'
Productization refers to the transformation of assets, skills, processes, ideas, technologies, data, and/or networks into a marketable offering (a product). This process is usually overseen by a Product Manager.
Google's various technologies for data processing have been combined into a suite of products called Google Cloud. Microsoft's document authoring, database, and collaboration tools have been combined into the Office 365 product/product line. Professional services from small business bookkeepers often get combined into a tax preparation 'product.'
Product thinking is an essential part of a digital factory; it prompts critical questions about user needs, company responsibilities, and financial viability.
In software development, a 'product' is more or less synonymous with an 'offering'—a bundle of functions and resources that solve particular customer needs.
Product managers coordinate the user, business, and technology stakeholders around a product, ensuring the product is viable, cost-effective, and valuable.
Product managers are responsible for the overall roadmap of an offering and serve as the primary point of contact for input from various groups of users and parts of the business. They are also often responsible for making or coordinating major planning, budget, and feature decisions.
They are responsible for creating and maintaining essential documentation and roadmaps such as Product Requirement Documents, Market Requirement Documents, and Software Requirement Documents.
During the Plan phase, leaders may use Design Thinking, a discipline spearheaded by IDEO, to understand users' needs in new ways.
"Design thinking is a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success."
—TIM BROWN, EXECUTIVE CHAIR OF IDEO
Where traditional software development is often biased toward what the business or the developers prioritize, design thinking prompts participants to engage in empathy and research about what a user needs.
Design thinking "draws from the designer's toolkit" to engage in early, on-paper ideation, observation, and interview of actual humans to ground development in truly usable software.
Where agile software development focuses on making the best software, design thinking guides developers toward designing relevant and viable software.
Product managers create and update several guiding documents to help the team align:
The product manager creates a Market Requirements Document (MRD) to define what the market requires of a particular product. It should include a list of features, details on competitors, and potential revenue.
In essence, an MRD is used to find answers to the key questions asked of any new product:
Product managers also create a Product Requirements Document (PRD) that details all features and functions a product requires to be considered complete and a use case for each. It is the source of truth for a product's development and launch—every detail of every feature is described within it.
The PRD is used to inform and shape numerous other documents and processes created during the development cycle, including software requirements documents, technical specifications, and UX wireframes.
A PRD should also include all assumptions (anything expected to be a factor but which is not guaranteed, such as all users having internet connections), constraints (limiting factors, such as budget or timeframe if the product is time-sensitive), and dependencies (anything that the product relies upon, such as SDKs and/or microservices).
User Experience (UX) covers all aspects of a user's interaction with a company and its technologies. This includes, but is not limited to, the user interface (UI) of apps and websites, customer service, retail stores, and digital properties (such as websites, social media, and content).
Consideration of user experience starts in the planning stage of DevOps but continues throughout the entire cycle. UX is most carefully observed and integrated during the Test, Operate and Monitor stages.
User experience tools are a critical part of the planning stage and are used throughout the DevOps cycle.
Collaborative whiteboarding software like Miro and Mural can help teams think through user needs and components (like datasets) which need to connect.
Design tools like Sketch, Figma, Adobe XD and Balsamiq help designers create wireframes (simple, skeletal line drawings of websites and apps) and, later, clickable prototypes ('fake' experiences to experience what an app will feel like).
Many of these tools now have direct exporting functions so that the work of the planning stages creates visual assets which can be used in later stages.
A user story is a prose description of what a user needs to do inside an app or service. User stories are often connected to a persona model.
Hypothetical user stories might read, "Indira wants to be able to quickly complete her user profile so she can start using the app," or "Cyreena needs to be able to export their bank transactions to save time during tax preparation season."
Product managers and developers prioritize user stories and map them to particular programming and integration tasks needed.
Persona models are a powerful way to create an abstraction of different sections of the customer base and other stakeholders who would interact with the product.
Persona models tend to look at the demographics of a user group, while more well-developed persona models also deal with sociographic and psychographic elements.
'Sociographics' refers to the networks of people those users are a part of, such as other families they know or their coworkers.
Psychographics refers to their worldview and emotional state, or the kind of archetypes they embody out in the world, such as 'caregivers' or 'engineers.'
These persona models focus more on how those customers view problems and perceive value and less on the functional tasks themselves. So a caregiver may be very emotionally motivated and concerned with helping overs, whereas an 'engineer' is more likely to be rational and scientific, with an outlook oriented toward problem-solving.
A well-developed persona model ensures that the software developers you're working with understand the users or customers. You can read more about persona models here.
Objectives and Key Results (or OKRs) are essential for decisions made in digital factories and DevOps teams.
Measures of success used in other business areas, such as Key Performance Indicators (or KPIs), are heavily focused on revenue rather than its precursors like software quality.
For DevOps to be effective, there needs to be an ongoing investment in core infrastructure and sometimes core R&D that is not directly related to revenue.
This is why startup software development is often funded initially through venture capital, which does not expect immediate revenue returns from technology investments.
When considering OKRs and other long-term business goals, balancing a short-term need for revenue with longer-term needs for fundamental digital capabilities is essential.
Once this balance is reached, return on investment can be seen through measures of software factory success, such as uptime, or how long the system is working versus not working. A good DevOps team will be able to decrease the amount of downtime considerably by patching more and more holes and building redundancy and resilience into the foundations of the software. Decreasing downtime also helps with other non-revenue OKRs, such as customer satisfaction and company resilience.
Effective digital firms practice what can be thought of as 'networked leadership'—an approach to strategy, decision-making, and communication which reconciles the necessity of alignment with the wisdom and autonomy of networks. This approach and its implementation are explored in depth in our Networked Leadership guidebook.
Having a highly collaborative culture is critical to digital factory and DevOps success. It is important to consider what kinds of thinking are needed at each stage of the DevOps cycle and in each season of innovation.
Read more about a simple but powerful mental model for balancing alignment and autonomy at different parts of the software development cycle in our decision principles guidebook.
A backlog lists all the technical tasks waiting to be done. Product managers, technical teams, and other stakeholders re-prioritize this list as necessary.
Prioritization of tasks sometimes involves delaying features or even fixes to a time where there is enough available time and engineers to address those changes. For example, aesthetic issues are not as high a priority as system-breaking problems, and security issues are far more important than those.
Backlogs can also be used to optimize workflow. If the team is aware of an imminent update to a particular feature, putting other changes to the same feature in the backlog provides an opportunity to work on multiple aspects of that feature once, instead of SEVERAL team members making many individual minor edits.
A sprint is a focused, accelerated work period for a team to complete a vital software development goal.
Sprints are useful because they minimize gaps and delays between various team members and are focused on supporting team members' 'flow states' for work. During a sprint, leaders take distractions off the calendar, articulate clear and achievable goals, and make themselves available to the whole team as much as possible.
Sprints are also helpful for rapidly iterating software between teams, such as when DevOps teams between departments come together to solve a common problem.
One of the social elements of the DevOps cycle is the daily standup: a meeting lasting less than fifteen minutes at the beginning of each workday.
Standups allow individual progress updates, socializing each individual's daily goals, and surfacing any minor obstacles impeding the current task's completion.
The brevity of a daily standup is necessary to keep the meeting on topic and isolate the most important aspects of the day's labor. It also allows colleagues to pair up on intersecting aspects of the current project. If problems require collaboration or further discussion, relevant parties can split off after the standup. This allows more efficient use of all employees' time—and avoids 'workplace TV' where everyone else sits around with nothing to contribute.
The daily standup is a practice that embodies the agile mindset—a quick check-in at the beginning of the workday to align (or re-align) a DevOps team. Called a standup because of how short it is (not enough time to bother with sitting down), a standup often only has three items from each participant:
At the end of every sprint, it is crucial to ensure that an appropriate review or retrospective (sometimes called a 'retro') is held. These are bonding moments for all participants to come together, share learnings, and, where appropriate, codify these learnings into new practices or decision principles.
These sessions offer a deeper understanding of not just users (via unexpected reactions, new user stories, and use cases) but also for spotting and correcting any organizational issues, such as lines of communication, working styles, and the availability of decision-makers.
Such feedback and learnings are vital to ensuring that any issues encountered during one cycle are dealt with as quickly as possible so as not to be re-experienced during every subsequent cycle.
A developer refers to someone who builds and manipulates software code (or sometimes digital hardware). The job of a software developer is to convert human needs into programs using computational thinking. They code particular instructions for machines to follow, either from scratch or by assembling sequences of ready-made components.
Software developers are core to the software development experience, but there are several disciplines within the field. Speak with IT leaders to understand the different kinds of software developers needed.
There are several types of DevOps teams, each optimized for different seasons of innovation and different product types.
Stream-aligned teams are focused on a single high-impact work area, such as a critical product, feature (like Facebook's early mobile team), user journey (like new member onboarding), or a single user persona.
Platform teams are more autonomous and emphasize work on shared capabilities inside a digital organization, such as the data processing needed by all of a company's apps or its security services.
Complicated sub-system teams focus on specialized functions, such as crucial microservices (like billing) or a specific machine learning model.
Enabling teams are groups of specialists who help other DevOps teams by integrating specific technical elements that the core team does not need to interact with, therefore removing obstacles and distractions.
Atlassian, a toolmaker for DevOps teams, explores some of these DevOps team strategies and team structures beyond the scope of this article.
Achieve your goals with the freedom and flexibility to build, manage, and deploy your applications anywhere. Use your preferred languages, frameworks, and infrastructure—even your own datacenter and other clouds—to solve challenges large and small.
Overcome challenges at every stage of remote engineering and learn how Microsoft engineering teams have enabled remote development.
Spend less time hunting things down and more time getting things done. Organize your work, create documents, and discuss everything in one place.
Use Google Docs to create, and collaborate on online documents. Edit together with secure sharing in real-time and from any device.
Plan, track, and release world-class software with the #1 software development tool used by agile teams.
Make amazing things happen together at home, work, and school.
The online collaborative whiteboard platform to bring teams together, anytime, anywhere.
MURAL connects teams with a digital whiteboard and collaboration features designed to inspire innovation.
Slack is your digital HQ Transform the way you work with one place for everyone and everything you need to get stuff done.
Number of experiments (technical, market, etc.) designed 'on paper'
Assumptions and possibilities documented; testing these leads to higher likelihood of offerings that are genuinely useful and feasible
Fully-written user stories (demonstrates listening to users which will lead to increased quality)
The Code & Assemble stage of the DevOps cycle is where hands land on keyboards. Developers use existing frameworks best suited for the project, select prewritten functions from code libraries, and write custom code when necessary to bridge any gaps between the building blocks they've assembled to produce the results they need.
This process is not unlike how a tailor will use existing design patterns (akin to programming frameworks) to fashion a suit. Even after selecting and cutting the pieces of fabric (code libraries) to hang on the pattern, the tailor will still need to make minor alterations to customize the fit (custom code) for each individual's needs. And just like with clothing, sometimes the needs can change between the time of the initial planning and the final product. Threads can break under pressure during assembly, or large dinners happen and the measurements change.
Source code refers to the lines of instructions that make up a computer program. Team members begin by practicing computational thinking—converting complex problems into unambiguous instructions for a machine. Programmers convert these instructions into machine-readable steps in programming languages (a bridge between how programmers think and how machines process instructions). Either they create something entirely custom or reuse patterns and frameworks made by others to perform standard functions. The collection of these steps and functions makes up the source code of a program.
When teams (or even an individual) begin software development, they have to have a place for source code to live. Source (code) control management, or SCM, refers to tools that allow developers to manage various pieces of code in one place. Git is one of the most popular SCMs.
A code trunk is the source code from which a software project originates and into which future code is merged.
In trunk-based development, copies made from the source code are known as branches, which remain connected to the core but extend outward from the trunk. Sometimes, a branch is found to be essential enough (or superior to the original code) that it becomes part of the trunk.
When a copy of code is made from its source and separated from that source, it is called a fork (like a fork in a road, it is a point of departure). This is distinct from a trunk-and-branch approach, which keeps the code connected in case of a need to coordinate future development.
When software has had significant changes completed, a commit is performed—a saved snapshot of all current work is logged into a code repository. This encapsulates all changes since the code was either a) created for the first time or b) 'forked' or 'branched' from a common body of code (stored in a code repository).
The concept is important even for non-coders to understand, as measuring the number, quality, size, and/or frequency of 'commits' is an important part of gauging a development team's velocity and health.
When coding, especially in a team, paying attention to code quality is vital.
This does not mean asking, ""Does it work?"" which is another way of saying, ""Does it work right now?"" To be considered a quality product, the code must remain stable even when given unexpected inputs. It must also be upgradeable, meaning the code should be well-documented and easy for other developers to use, with a uniform writing style (including spaces and choices of syntax).
Much like a group of authors writing a textbook, the finished product should be accessible, concise, and pass the information along uninterrupted.
As far back as punchcards, programmers have been reusing code. These collections of code are purpose-driven, each with advantages and pitfalls.
Some are large, providing a framework to build the software with internal dependencies that their respective creators have already worked out. Others are smaller Code Libraries, where you can select one small piece from the whole to answer a specific question or fill a particular need.
Frameworks are larger, interdependent systems of code repositories that can be designed around general functions.
Node.js is a popular framework employed by websites like LinkedIn and Netflix, where it is vital to deliver complex graphics seamlessly, customized to the user's interests and focus.
In contrast, data scientists would have more use for Apache Spark: a framework with features designed to solve complex calculations at a staggering scale but only needs to display numbers and graphs. Capturing a beautiful visual aesthetic is never necessary for this situation, so graphic bells and whistles would not be included in that Framework.
After selecting a framework that can provide desired results, engineers will begin integrating premade modules from Code Libraries to adjust the function of the Framework to their intended purpose.
Cybersecurity is a critical concern for all digital factories but often is not considered in the earlier stages of software development. This is partly due to the Security and Compliance departments being seen as barriers to innovation, 'dream-killers' whose boundaries quash possibilities.
In practice, however, good cybersecurity planning and toolkits enable innovation. Organizations that handle data securely as a matter of course will be able to take on daring innovations their competitors can't risk.
For example, Apple's secure HealthKit, ResearchKit, and CareKit APIs enable healthcare providers, end-users, and researchers to analyze personal health information, sometimes without the underlying data ever leaving a user's device or control.
Compared to less-secure systems from decades past, this drastically lowers the risk and cost of healthcare research. At the same time, Apple's APIs are broadening and diversifying sample sizes—as of March 2022, Apple's health and movement study has over 175,000 participants.
The concept is important even for non-coders to understand, as measuring the number, quality, size, and/or frequency of 'commits' is an important part of gauging a development team's velocity and health. "
Like most timelines in Western culture, development processes are shown from left to right on a process chart. So, 'shifting security left' refers to addressing cybersecurity concerns as early as possible, compared to conventional processes that sometimes don't involve security experts until late in the software development journey.
By considering security issues early, leaders have more time to respond to future needs. They can also suggest design principles to lessen potential expensive delays or wasted development efforts.
Development Security Operations (DevSecOps) involves addressing security considerations throughout the development of the product.
"AWS CodeCommit is a secure, highly scalable, managed source control service that hosts private Git repositories. CodeCommit eliminates the need for you to manage your own source control system or worry about scaling its infrastructure."
"Enterprise-class centralized version control for the masses"
Collaborate on code with inline comments and pull requests. Manage and share your Git repositories to build and ship software, as a team.
Search, monitor, and track across SVN, Git, and Perforce repositories.
Millions of developers and companies build, ship, and maintain their software on GitHub—the largest and most advanced development platform in the world.
From planning to production, bring teams together in one application. Ship secure code faster, deploy to any cloud, and drive business results.
Plan, track, and release world-class software with the #1 software development tool used by agile teams.
Amount of time spent actively creating code in an editor or integrated development environment (IDE)—measures 'flow state' for developers
Number of submissions of code to a repository (may use specific 'successful' or 'functional' if needed)
Number of code commits integrated into the trunk branch per developer per day
Duration of a given iteration (eg, a sprint, a 'small size t-shirt' etc)
Sum of additions and deletions of code integrated into a code trunk or main branch (should couple with quality measures)
The Build stage of the DevOps cycle is where all previous coding and assembly work comes together. The various threads of work building each aspect of the software are compiled and tested as a unit in a controlled environment.
A project will cycle between its code & assemble, build and test stages until it reliably produces error-free, accurate results.
Teams of engineers keep all their work organized using a code repository. Alongside the code itself (including trunks, branches, and forks), these repositories also hold documentation, notes, and error reports.
Code repositories can exist on both the developer's computer and their team's servers or cloud instances.
There are a variety of platforms that manage the organization and merging of code branches, trunks, and forks. The most popular is Github, but others, including Bitbucket and Gitlab are also widely used.
Red Hat® Ansible® Automation Platform on Microsoft Azure offers all the benefits of Ansible automation, with the convenience and support of a managed application. This offering is fully supported by Red Hat and deployed in your Azure cloud.
Apache Ant is a Java library and command-line tool whose mission is to drive processes described in build files as targets and extension points dependent upon each other. The main known usage of Ant is the build of Java applications. Ant supplies a number of built-in tasks allowing to compile, assemble, test and run Java applications. Ant can also be used effectively to build non Java applications, for instance C or C++ applications. More generally, Ant can be used to pilot any type of process which can be described in terms of targets and tasks.
Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
Continuous integration, deployment, and release management.
Collaborate on code with inline comments and pull requests. Manage and share your Git repositories to build and ship software, as a team.
Automation Software for Continuous Delivery of Secure Applications and Infrastructure
Spend less time hunting things down and more time getting things done. Organize your work, create documents, and discuss everything in one place.
Accelerate how you build, share, and run modern applications.
Millions of developers and companies build, ship, and maintain their software on GitHub—the largest and most advanced development platform in the world.
From planning to production, bring teams together in one application. Ship secure code faster, deploy to any cloud, and drive business results.
Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
Automate infrastructure on any cloud : Provision, change, and version resources on any environment. Deliver infrastructure as code.
- Buildout, an automation tool written in and extended with PythonBuildout, an automation tool written in and extended with PythonBuildout is a tool for automating software assembly.- Run build tools to build software.- Apply software and templates to generate configuration files and scripts.- Applicable to all software phases, from development to production deployment.- Based on core principles: - Repeatability - Componentization - Automation
The CLI tool gluing Git, Docker, Helm & Kubernetes with any CI system to implement CI/CD and Giterminism.
Duration of a given iteration (eg, a sprint, a 'small size t-shirt' etc)
The Test stage verifies that the software functions properly and as expected by users. Testing can be manual or automated.
Test-Driven Development can ensure errors don't make their way into production code. These tests can even be designed before the program is built. Unit tests address individual sections of code and can be run during or before the build stage is complete.
In contrast, functional testing takes place after the software has been compiled. This tests the program, as opposed to its component parts, ensuring the system is performing as expected.
Continuous testing is a core tenet of DevOps, regularly running tests throughout the development lifecycle and, where possible, automating such tests to reduce friction and increase quality.
Continuous testing contributes to the continuous improvement of software and supports continuous delivery.
Unit tests verify that specific functions perform as expected, more or less on their own. Unit tests are often the first tests performed by a dev team. If a function does not pass, there is no point in progressing.
Integration tests ensure multiple components of software behave together. This can be inside the boundaries of a specific program (such as components inside your phone's text messaging app) or between programs, systems, or services (for example, between a text messaging app and a third-party GIF-finding service).
An acceptance test focuses on whether a component meets its various requirements. For example, the 'Buy Now' button in a coffee company's e-commerce app triggers the right actions for a warehouse to send a bag of coffee to a customer.
Acceptance tests fall into many categories, such as:
User acceptance testing (UAT) refers to real-world checks of software by actual end users. A user acceptance test can sometimes occur on 'alpha' stage software which has limited functionality and low reliability, but most UAT occurs on beta-stage software, or even 'general availability' (GA) software.
The concept of UAT occurring during the GA phase represents a shift in thinking about how 'finished' software should (or even can) be in a technological landscape which evolves so quickly. For example, Microsoft and Apple email software was shipped as 'general availability' software, with users who expected to rely on it absolutely. Yet Google's Gmail software and service was labeled a 'beta' release for a very long time—years. When users were upset with Apple or Microsoft failing them, it was because they were marketed reliable software and were then disappointed when it didn't work. But Gmail carefully managed expectations about how well it functioned so that Google could regularly iterate new changes in the software.
Fast, easy and reliable testing for anything that runs in a browser. Install Cypress in seconds and take the pain out of front-end testing.
Intelligent Test Automation for Agile TeamsEasily create reliable end-to-end tests that improve application quality without slowing you down.
Selenium automates browsers. That's it!What you do with that power is entirely up to you.Primarily it is for automating web applications for testing purposes, but is certainly not limited to just that.Boring web-based administration tasks can (and should) also be automated as well.
Automated UI testing that covers you from device cloud to packaged appsEnsure the quality of your application without sacrificing speed or agility with an easy-to-use, GUI test automation tool.
Number of tests passed at a unit level
The Release stage is the fulcrum where a product goes from creation to delivery. At this point, developers have created, tested, fixed, and retested a product to satisfaction, certifying that it is ready to be deployed.
If the product were a book, this is the point where, after a series of drafting and proofreading, everything can 'go to print.'
Continuous integration is the practice of constantly bringing new changes to code into use rather than waiting until a large, critical mass of changes occur.
While continuous integration causes some additional work (usually helped by machines), it also solves other problems, such as not seeing how new code and its interdependencies operate in the real world until too long into the process to change that code easily.
Continuous integration, deployment, and release management.
Collaborate on code with inline comments and pull requests. Manage and share your Git repositories to build and ship software, as a team.
The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project.
Plan, track, and release world-class software with the #1 software development tool used by agile teams.
Number of initial, partially-functional digital releases.
Number of functional early software releases
Average of an organizations' percentile rank across Delivery Frequency and Delivery Lead Time
Number of General Availability (GA) releases (public releases which are not alpha or beta stage)
Measures responsiveness of a software team to users, supports a high-quality experience and builds trust
In the Deploy stage, the Operations team takes the helm as the newly-minted release is shipped to customers!
Many factors determine how a release is deployed, including:
Historically, deployment was a manual act; however, in a continuous improvement and integration model, the most up-to-date version is automatically in use as soon as it is ready.
Continuous Delivery (CD) refers to developing software in short release cycles that regularly deploy incremental updates. Devs can monitor newly-deployed software to ensure users are satisfied, security is maintained, and other goals are fulfilled.
Continuous delivery works best in environments where users are always accessing the newest software (as is the case when using cloud apps) or where their devices regularly synchronize apps (the default setup for smartphones that automatically install app updates).
DevOps and CD also work best when there is a clear and detailed feedback loop to software developers about how the software functions for users. Modern analytics tools help considerably, showing which features people use, how they navigate websites, and what they do with data.
For example, at the time of writing, Chrome is on version 100.0.4896.88. There have been one hundred significant software releases and thousands of sub-releases since it was launched, rather than simple annual version updates.
The practice of releasing an annual software version was pioneered by Quicken, and its parent company, Intuit. Their software involved personal financial management, which needed to be updated with the most recent tax laws each year.
Other software companies, such as Adobe, followed suit. There is no critical functionality requiring Adobe to version their software by year, a significant annual update is helpful for user expectations.
For example, a professional video editor using Adobe Premier needs a consistent and stable experience. If they were to log in one day and find that the entire interface had been updated without their knowledge, it might severely impact their ability to complete their work on time. So, while the software automatically performs minor updates to fix bugs and issues, Adobe leaves it up to the user to decide when is a convenient moment for a more noticeable change.
Continuous deployment builds on continuous delivery but automates more of the process.
AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during application deployment, and handles the complexity of updating your applications. You can use AWS CodeDeploy to automate software deployments, eliminating the need for error-prone manual operations.
Automate continuous delivery pipelines for fast and reliable updates
The leading cloud platform.
Red Hat® Ansible® Automation Platform on Microsoft Azure offers all the benefits of Ansible automation, with the convenience and support of a managed application. This offering is fully supported by Red Hat and deployed in your Azure cloud.
Collaborate on code with inline comments and pull requests. Manage and share your Git repositories to build and ship software, as a team.
Build powerful, automated workflows: automate your code from test to production with Bitbucket Pipelines, our CI/CD tool that's integrated into Bitbucket Cloud.
Accelerate how you build, share, and run modern applications.
The leading open source automation server, Jenkins provides hundreds of plugins to support building, deploying and automating any project.
Innovate with infrastructure automationPuppet is redefining what’s possible for continuous operations. Easily automate your environmentto deliver at cloud speed and cloud-scale with products that are responsive and predictive by design.
Find and automatically fix vulnerabilities in your code, open source dependencies, containers, and infrastructure as code — all powered by Snyk’s industry-leading security intelligence.DEVELOPER SECURITY FOR TEAMS OF ALL SIZES
Source code is your software asset. Code is at the core of your software and dictates its behavior and performance. Clean code ensures that your software continues to be an asset—not a liability—and is the key driver for today's business success.
Number of integrations of apps and services that reached a beta state
Amount of time needed per deployment of code
How often a DevOps team successfully releases software to production
Time from project beginning until successful 'live' deployment
The Operate stage is the domain of the traditional IT department, focusing on servers and systems which host applications. The tools and processes for ongoing IT operations are as numerous and varied as the developer's coding languages. They involve stacks (or collections) of tools that run servers, read and analyze databases, and generate user-facing apps. These tools also can be used to monitor website traffic, identify software requests, and track performance.
Infrastructure in technology companies has traditionally been viewed as servers, file storage, and which access permissions are relevant to specific users. This was generally a manual process where someone had to configure machines, add them to a data center, and physically secure them.
Infrastructure as code or 'elastic services infrastructure' allows a simple line of code or a corresponding graphical interface to launch a new server in a virtual environment, immediately available for all relevant users to access. This significantly reduced the lag time for developing new servers, data storage solutions, and new processing capabilities. By literally connecting different departments and proportioning one giant pool of storage and bandwidth through software-defined means, it was easier to configure and reconfigure infrastructure.
Companies like Amazon Web Services can set up new user accounts and immediately offer access to a new place to stage and develop your applications to test them in a 'sandbox' area isolated from the real world.
The ability to scale up or down the amount of resources a project uses is much easier when it's software-defined rather than hardware-defined.
This ability or otherwise to scale quickly became apparent during COVID when some companies involved in remote work needed specific online tools to be used more than initially envisioned. Those who relied on cloud solutions such as Google or Amazon Web Services could quickly scale up nearly infinitely. Others, dependent on proprietary or custom-built approaches that didn't scale up, struggled to match them.
For example, companies that required all of their employees to use their virtual private network for video calling suddenly choked because their network couldn't handle that many people using it simultaneously.
Policy as code is similar to infrastructure as code but refers to the ability to enforce rules and decision principles upon software instead of people.
Company security policies, such as which users get access to what servers, etc., are manually configured or managed in broad groups that don't always reflect the nuance of what individuals may need to do.
For example, as part of a new hire's onboarding, an administrator may grant them access to specific software or ensure they have access to sensitive materials to do their jobs. With policy as code, you can automatically make accessible various services, devices, and datasets to a given user.
Another example of policy as code is determining where data should be stored based on the user's locality. As data sovereignty laws change, the relevant data officer can enforce a new policy across an entire set of users automatically and seamlessly, rather than through a manual process.
Instead of being manually configured, making policy codable lowers the cost of managing particular user experience elements.
Containers are lightweight packages of application code along with just the things it specifically depends on, such as specific versions of programming languages and libraries required to run a component of software being programmed. Containers are similar to virtual machines in that they comprise everything needed to run the software, but instead of being a dedicated 'machine' (akin to a desktop PC that only runs one part of the program), containers don't bring along an entire operating system with them. Containers allow software developers to quickly move a working component between servers and their personal machines, without the amount of time and resources needed to deploy a full computer's worth of functions every time. Containers help the DevOps cycle run smoothly by making handoffs and deployment easier, lowering the IT overhead (and security risks) for continuous software development efforts.
Notify the right people at the right time with powerful incident alerting and on-call schedules
Incidents happen. Keep your users informed and ditch the flood of support emails during downtime.
Zendesk makes customer service better. We build software to meet customer needs, set your team up for success, and keep your business in sync.
Times a given API has been accessed (may be divided by the number of unique users making the calls)
Application performance index expressed as a weighted average of users satisifed, tolerating a service, or frustrated.
How long an application takes to perform a triggered transaction
Percentage of a cohort's new users who are (satisfied, properly onboard, converted, etc) in a set period of time vs. percentage of prior cohorts of new users
Number of customer tickets opened in a given time period (expresses either dissatisfaction or occasionally positive engagement)
Number of mistakes made by a system, which may or may not be due to a defect in programming
Time needed to detect a failure, error or defect
Category of metrics tracking specific performance relative to promised or targeted service levels
Amount of time a service remains operational (usually expressed as a percentage over a given time period)
This stage is also sometimes termed 'continuous feedback.' Operations and customer support teams track website or server availability, software errors, and, most importantly, customer input. This input is harvested by tracking the frequency and severity of bug tickets, direct user feedback, and passive monitoring like site analytics, tracking a user's activity and conversion rates.
The data from this stage feeds back to the planning and coding stages continually, informing future design planning and upcoming version releases.
The monitor stage covers both the development process and launched products, services, and applications. The goal of monitoring is to quickly find and resolve issues that affect:
In DevOps methodologies, teams attempt to create automatic notifications of changes, high-risk actions, or failures to minimize downtime. Alongside this, of course, manual alerts are also used.
Observability refers to the quality of being able to see each part of the development and operations processes. Conventional approaches were not always visible to business stakeholders or even among technical teams, making progress difficult to predict and accountability challenging.
DevOps prioritizes 'instrumentation' of both development and operations so that all parties can see how the entire system of people and machines is functioning.
Transform your applications and business with AppDynamics real-time performance monitoring.
Modern monitoring & security: see inside any stack, any app, at any scale, anywhere.
Excel at customer experience in a world of changeㅤQuickly pivot based on your customers' feedback and drive more value for them—and your business.
Your monitoring data displayed on beautiful graphs and dashboards - with alerting.
Understand how users behave on your site, what they need, and how they feel, fast.
Collaborate at high-velocity, respond to business changes and deliver great customer and employee service experiences fast.
Plan, track, and release world-class software with the #1 software development tool used by agile teams.
Notify the right people at the right time with powerful incident alerting and on-call schedules
Software that makes your software better: helping you deliver better product experiences for happier and more productive users.
Slack is your digital HQ Transform the way you work with one place for everyone and everything you need to get stuff done.
The Data Platform for the Hybrid WorldGo from visibility to action, fast and at scale — for security, observability and beyond.
Incidents happen. Keep your users informed and ditch the flood of support emails during downtime.
Times a given API has been accessed (may be divided by the number of unique users making the calls)
Application performance index expressed as a weighted average of users satisifed, tolerating a service, or frustrated.
How long an application takes to perform a triggered transaction
Percentage of a cohort's new users who are (satisfied, properly onboard, converted, etc) in a set period of time vs. percentage of prior cohorts of new users
Number of customer tickets opened in a given time period (expresses either dissatisfaction or occasionally positive engagement)
Number of mistakes made by a system, which may or may not be due to a defect in programming
Time needed to detect a failure, error or defect
Category of metrics tracking specific performance relative to promised or targeted service levels
Amount of time a service remains operational (usually expressed as a percentage over a given time period)
DevOps is not a simple or universal methodology. It is a set of mental models, decision principles, and tools that round out (or sometimes replace) highly-controlled certifications, carefully unified technology stacks, and other approaches to development and IT.
