From The Agile Advocate: Musings on DevOps

From The Agile Advocate: Musings on DevOps

First in a series.

Paving The Way To DevOps.

 

Introduction

For more than 30 years, I’ve been involved in multiple large, enterprisewide, mission critical application development projects. Along the way, I’ve also developed and brought to market several products. In looking back at these projects, the common thread in the successful ones was the ability to respond quickly and effectively to the changing needs of the end user. Whether these changes were the result of vague or misunderstood requirements, a changing technology landscape or competitive pressures, the ability to react quickly without regressing was critical to success.

Getting theses projects and organizations in an agile posture came with a litany of trials and tribulations. Without a doubt, organizations embarking on their journey to DevOps will encounter many of these same challenges. Yet, the benefits are substantial and worth the effort.

With this series, I wish to share these past experiences and observations - both the successes and the failures - so others may avoid or minimize the pitfalls I encountered. My hope is to smooth out the road to a successful adoption of DevOps.

 

Policies, Procedures and Standards

The automation of old manual legacy processes for building, testing and delivering product seems to be the first thing most organizations jump into right away. And why not? It’s tangible proof to management and the end users DevOps is happening and you’re making progress.

But before starting the implementation of your Continuous Integration/Continuous Deployment platform, first you must establish the policies and procedures, along with best practices and standards, around its use, as well as roles and responsibilities in the organization.

Given the platform will likely be used by multiple teams within the project and possibly even from across the organization, it’s imperative standards involving onboarding, repository management and branching, development, testing, documentation and deployment are clearly articulated and understood by each team. This means detailed documentation about these expected practices and standards are accessible. In addition, creating a training plan to assist development teams in the implementation of and compliance with the policies and procedures is a big plus for adoption.

One of the most valuable documents you can produce is a reference model. The reference model serves to frame and facilitate discussions pertaining to the adoption, implementation and continued use of the CI/CD platform. It also serves to provide definitions for components such as an environment, release candidate and end-to-end testing, and helps in reducing ambiguity and confusion.

Particular attention should be paid to the establishment and enforcement of coding and testing standards. With today’s technology, substantial support for formatting and style checking, static code analysis, documentation checking and application code security checks can be achieved within the automated build process itself. However, while much of this can be handled by automation, there still exists the need for coding and documentation standards that provide initial guidelines and a governance process to ensure the standards are being followed.

Your automated build process is the core component of the CI process and should be initiated whenever code is committed or pushed into the code repository. This process will encompass all the steps required to build the end product for that code base including, but not limited to, static code analysis, compilation and testing and packaging code. The build is considered a barometer on the quality of your code base and ultimately your product. If code is pushed into the repository that breaks the build or does not allow it to complete successfully, then it should be considered a broken build. Developers should not check in code that breaks the build, but if one does, fixing it should be considered their highest priority. One of the most important policies to articulate and enforce is: “All other work stops until the build is fixed and working again.”

It’s not the most exciting thing you’ll do concerning DevOps, but getting the rules and guidelines along with your expectations for an end product and what that actually encompasses will lay the foundation for your success. Next time, we’ll talk about how these practice and principles come into play in leveraging the cloud to achieve the optimal delivery cadence for your organization.

Add new comment

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.