Estimated reading time: 6 minutes
Read about the history of DevOps from a 2016 article by Steve Zoppi.The concepts surrounding DevOps (development/operations) structure are complex and continue to evolve to encompass a wide range of practices and processes.
Read one of the best explanations of DevOps.
This particular perspective expresses the nuance that the TIER Working Group teams have had to navigate in constructing their response to the community requirements.
At first, the community’s vision for the evolution of TIER components borrowed more heavily from the disciplines of agile software development. However, given the evolving needs and capabilities of the community and the demanding campus environment, this development process was ruled out in favor of a hybrid DevOps methodology which the initiative has now adopted.
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
Background
Reflecting on the community-defined TIER requirements, two general themes emerge:
- Build components, processes, and practices
- In the most reliable, manageable, and predictable manner possible
- While producing secure, dependable, extensible and flexible solutions that can be easily maintained by campus practitioners
These two themes seem simple enough, but their implementation is quite complex. Inherent are two process requirements for producing TIER-associated products, documents, and practices. The development process must include:
- Repeatable, consistent development cycles and pathways; and
- Continuous peer-reviewed and approved involvement by the community in a uniform way
This complexity is amplified first by the spectrum of implementation/campus needs, but also by the number of components developed by autonomous teams whose activities need to coalesce into a coherent deliverable.
Requirements and Constraints
Early in the articulation of the TIER mission, we described a path from concept through delivery that was largely aspirational. We have since informed our thinking by what is practical through the experienced eyes of community practitioners. What has emerged is the acceptance and accommodation of limits (funds, subject matter expert availability, and time) while placing greater emphasis on the areas considered luxuries in the past, including:
- Automation of the build, test and packaging cycles.
- Rigorous articulation, definition, ratification, and publication of standard APIs (application programming interfaces), data structures, and component delivery vehicles.
While the working groups concluded that adoption and deployment of the arising work is crucial to sustaining the delivery lifecycle, they also faced clear constraints:
- Although the program could deliver at a fixed cadence, the relatively small number of potential adopters would seldom be synchronously ready to absorb the deliverable without creating disruption in their environments.
- New features and functionalities were being requested and considered at rates too disruptive to reliably conduct security audit, test, acceptance, and refinement cycles.
Resulting DevOps Environments
Considering these constraints — in combination with the expectation that security system software requires a higher quality and integrity confidence level that could otherwise deliver at a rapid pace — it was determined that two separate and distinct software development pathways needed to be created. These can be thought of as “workbenches.”
These two workbenches have essentially the same infrastructure and technology bases, but completely different outcomes, with differing quality and release criteria.
The Demo Workbench constitutes a pathway in which the primary objective is to provide the functionality recipient an opportunity to “kick the tires” and see the functionality in action as soon as possible. In this mode, partial implementations, performance issues, and other qualities may be subordinated to the goal of ensuring that functionality meets the needs of the implementer.
The Production Workbench takes everything crafted within the Demo Workbench to the next level. On this workbench, the emphasis shifts to completeness, quality, security, validation, performance benchmarking, as well as other attributes required of a release worthy of production deployment.
Graphics by Bill Kaufman/Leslie Jonas
Pathways to Delivery
- Demo Workbench: Interim Function/Feature Deployment → Demonstration → Suitability/Usability Test → Acceptance/Rejection
- Production Workbench: Production Integration → Build → Test → Release
The first pathway (Demo Workbench) is crucial because it enables the community to assess, refine, accept, and reject functionality in a full-working microcosm of the multilateral federation context on a very small scale in rapid iteration. Although the first pathway may lead to the second pathway (Production Workbench), this will not always be the case, because features will be tested and rejected in the first pathway and may never see the light of day in production (the ultimate goal of the second path).
DevOps is also characterized by operations staff making use of many of the same techniques as developers for their systems work.
The Demo Workbench must never become a dumping ground for every requested feature; instead, it will support the integration of services being proposed by the community in a controlled manner. It should be thought of more in the context of a “showcase” versus a “testbed,” even though it will have no service level associated with it. There will be an expectation of availability where certain components are concerned and those will be maintained on a best-effort service level basis.
To keep clutter to a minimum, the Demo Workbench will include a timeline for acceptance or rejection of each component and feature being showcased. The added benefit of the showcase approach is that many can work concurrently and somewhat independently in the environment, with minimal orchestration. This environment will include release and configuration management just as in production environment, but it will not undergo the same rigors of security testing, documentation, and performance testing that a production path/quality release would normally prescribe.
As new functionality is developed (such as that of the new consent service), it will continue to reside in this workbench until it is feature and function complete. At that time the functionality will continue through the user acceptance testing process until the product is ready to undergo configuration on the Production Workbench. The Demo Workbench may also be a place in which support of new federation functionalities can be constructed. Ensuring that the Demo Workbench is a proper superset of the InCommon Federation environment at all times will ensure high-fidelity testing of all constituent components.
The Production Workbench pathway must always be targeted only after having first gone through the Demo Workbench pathway. This Production Workbench is actually the “Release Pathway” for the campuses and cannot simply be a copy of, or derived from, the Demo Workbench implementation. This Workbench requires the rigors of security analysis, performance analysis, code review, documentation review, and more. The Production Workbench will include the fashioning of instrumentation for measurement, test, and audit, performance measurement, and other time-intensive rigging that would be considered superfluous in the Demo Workbench, and conserves the more labor-intensive activities for the production-targeted resulting work.
Conclusion
By utilizing these two pathways—Demo Workbench and Production Workbench—in complementary ways, the community can always test and verify functionality and features that contributors and sponsors are exploring in a much more high-velocity and interactive way and in an environment that functions just like the real world—without negatively affecting the real world. Then, upon community acceptance and implementing the rigors of a more disciplined pathway, accepted features may be properly integrated, security tested, and deployed into the release pathway for campus adoption into their production environments.