Putting up DevOps guardrails -- what does that mean?

What purpose do guardrails serve?

When designed and implemented properly, guardrails bring four principal benefits to DevOps teams and businesses in general:

1. Guardrails limit behaviors. Guardrails create a space where developers and managers are free to make decisions and operate. This doesn't preclude decisions outside of those guardrails, but the decisions might require additional discussion or approval.
2. Guardrails maintain collaboration. Guardrails help all members of the development team move in the same direction with the same goals. For example, stakeholders define which goal or problem the project must solve, and developers define how to solve that problem. Guardrails create an environment where developers can make decisions independently.
3. Guardrails enable faster decisions. Because guardrails limit behaviors and responses, IT teams can reduce significantly the time needed to act or respond to a given situation. For example, if coding standards define variable naming characteristics, it's easy to determine whether a variable name meets that particular guardrail.
4. Guardrails mitigate risk. Guardrails help reduce errors and rework, both of which can result in more time -- and cost -- for the business. Well-developed and accepted guardrails can increase project velocity and quality.

Where are DevOps guardrails needed?

Guardrails in DevOps environments can appear in many forms for a wide variety of purposes. Although the need for guardrails will vary dramatically with each project's size and purpose, as well as the nature of the business, DevOps guardrails relate to four major aspects of software development:

Coding

Code quality guardrails guide developers to create clear, concise, efficient, secure and maintainable code. These guardrails ensure the entire development team creates clean code -- in the same way, against common standards -- and that any developer can read and work on the code created by other developers on the project. This reduces coding errors and saves time and money.

Process

Process guardrails guide the iterative cycle and define process-related guidance, including repository management -- such as version controls -- testing requirements, recommended tool sets, release approval and deployment criteria, as well as documentation. These guardrails help facilitate smooth and consistent iteration cycles that keep projects on schedule and within budget.

Business

Business guardrails relate to the business aspects of the DevOps project. For example, these guardrails establish project goals and requirements; set budgets, including budget approval and contingency planning; assign roles and responsibilities, such as assigning project managers and team leaders; and establish communication and collaboration goals, such as issue tracking and regular project meetings with developers and stakeholders.

Special circumstances

Projects might feature unique requirements, such as real-time functionality with low latency for military or industrial applications, or be subject to specific regulatory requirements, such as the Payment Card Industry Data Security Standard or HIPAA. Such circumstances necessitate additional guardrails in coding, process and business to ensure compliance.

DevOps guardrails examples

There are many examples of guardrails that shape and direct DevOps projects. Consider a variety of examples in the three main categories: coding, process and business.

Common code quality guardrails

• Coding standards guide structure, punctuation and variable naming conventions through criteria for algorithm and module creation.
• Documentation standards detail how to document and prepare software for developer and user consumption, including the use of code comments and documentation vehicles such as web-driven wikis or conventional text files.
• Vulnerability and security guardrails set requirements for code hardening -- usually in conjunction with coding standards -- such as credentials and data encryption.
• Guardrails should limit open source code in commercial projects -- or require careful code examination and vetting against other code quality standards before incorporating open source code.

Typical software development guardrails

• Detail the specific tools developers can use for the project. The list can include several preapproved alternative tools from which to choose -- such as one test platform for test-driven development and another test platform for integration or performance testing -- but all tools should interoperate across the entire toolchain.
• Use testing standards to define the number and types of tests the project requires, set pass/fail criteria, and require automated testing while limiting manual or ad hoc testing.
• Use a regular or recurring post-mortem process at the conclusion of every iteration cycle, or sprint, where developers can discuss problems or challenges.
• Track and define various metrics, reporting and alerts as related to development efforts, such as tracking defect rates. Also track time to remediate defects and code quality assessments. Organizations use metrics to follow performance over time, and development metrics deliver objective insight into development effectiveness.

Business guardrails

• Establish clear project leadership and team structures. For example, a business might create a DevOps organizational chart to show clear lines of responsibilities.
• Take an active role in setting both project requirements and change criteria. For example, guardrails might require a complete suite of goals at the project outset and set clear limits on the addition of new goals or user stories to limit scope creep.
• Budgets and contingencies should provide clear funding to meet well-considered project cost estimates, along with limits on additional spending without clear discussion and approval.
• Business guardrails can define how project stakeholders collect and use metrics to assess progress.

How to implement and enforce DevOps guardrails

Guardrails represent a series of preferences and best practices, rather than immutable rules. Every business and development team is different, and consequently, there is no single way to implement and enforce DevOps guardrails.

Guardrails are typically the result of experience and understanding: Perform X activity in Y process; use tool A to achieve result B. Guardrails often are a response to past mistakes or unintended consequences, which means they evolve over time. Developers and business leaders understand their value, and most guardrails can be implemented with little difficulty once stakeholders reach a consensus.

Implementation is informal and can involve little more than a document outlining the relevant guardrails. Guardrails that depend on tools (e.g., an issue tracking system) or metrics (e.g., watching defect or rework rates) require a more formal approach. But experienced teams realize that guardrails provide indispensable alignment.

Enforcement can also span a wide range, depending on the business, project, guardrail type and violation degree. Most enforcement is informal or the result of an issue.

For example, if a developer inadvertently commits a minor violation of code quality guardrails, this simple mistake can be corrected easily through peer review or a code checker. But a developer who disregards code quality standards regularly might require intervention from a team leader or manager through additional education and other employment action.

Similarly, a stakeholder might demand additional features and functionality, such as user stories, as the project progresses. While guardrails set limits on such additions -- because of the additional development time and cost that new features demand -- those limits are rarely absolute. Guardrails must accommodate some level of change. However, frequent and significant changes could require a reassessment of the project scope, schedule and budget.

The most effective guardrails are approached as collaborative discussions, wherein business leaders involve managers and developers to craft and agree on a set of guidelines that offers clarity of purpose as well as the flexibility to recognize and respond to new ideas. Once a DevOps team buys into a set of guardrails -- or at least understands the need for them -- the project stands a better chance of success.