DevOps methods attempt to improve on traditional development, and the third way of DevOps  encourages experimenting to find new processes and techniques that might work better than the status quo. As teams and groups find and create more efficient processes, they improve the entire process. When all areas improve, in both development and operations, the pipeline improves at a global level.

Automating Standardized Processes

Automation is a key way to improve an entire process. Anything that can be made to work automatically, without much or any human intervention, will almost definitely improve a pipeline and allow team members to focus efforts elsewhere. In addition to requiring less effort, automated processes also remove the risk of human error. Where a team member might perform actions inconsistently, or occasionally wrong, automated systems almost always satisfy their requirements under the same conditions each time. The exception would be when there are problems with the automation, and proper logging can often identify this and alert team members of some problem that must be addressed.

While automation is valuable, not every process can automated. In particular, processes that are not standardized are not readily automated. Processes that are reactionary, with execution that differs based on results, are often difficult or impossible to automate. In these cases, a team member may still be the best and most efficient choice. Organizations should be careful not to get so infatuated with automation that they waste time and effort on processes that genuinely require human interaction.

Just because a process can be automated, this does not mean it should be. Teams might work toward automating a process that can be made more efficient or removed entirely. In these cases, the team has wasted effort toward setting up automation unnecessarily. Before automating any process, the team should examine whether it is necessary, or whether it can be obviously improved. Nearly every process can be improved or reworked, but some processes may already be reasonably efficient, and work about as well as can be expected. If the process seems pretty solid to the team, it may be a good candidate for automating. Instead, if the process is due for a rework, the team should focus on improving the process first, before applying any sort of automation.

Shared Source Code Repository

Writing code is often like putting a puzzle together, and it is very difficult to assemble a puzzle without all of the pieces available. Similarly, writing a cohesive software product is easier when teams have access to all code for the product. Because projects work better when all teams have access to all code, a shared source code repository is often the best way to allow access to code across an entire organization.

An organization with a shared source code repository facilitates automation. Any team can examine where other teams have automated processes, and mimic that same automation for their own purposes. Similarly, teams can recycle routines and methods used in other areas if they might be applicable to other parts of the product. Much like reinventing the wheel, it would be wasteful for multiple teams in an organization to write essentially the same code when it could be written once and applied in multiple areas.

To prevent unnecessary code changes and reduce the risk of sabotage, the organization might allow all employees to see all code, but only permit changes and commits with certain authorization. For a more lax approach, an organization might allow commits globally, but alert certain key members when changes are made, as a sort of confirmation. If suspicious changes are committed to the repository, the organization might investigate these changes and roll them back if necessary.

In addition to allowing multiple teams to see the same code, a shared repository might accommodate for one team viewing code in multiple different areas or languages. Instead of equipping every new employee with a different license or authorization for each area that they might work in, a shared repository allows one identifier to serve as the key to access any necessary code base. When a team brings on a new employee, they can give the new member authorization once, and know with certainty that all code is available as necessary.

Automated Tests as Documentation

Many software development experts say that code should be “self documenting.” What they mean is that there should not be a need for specific documentation texts, but rather that anyone working on code should be able to understand what the code is trying to accomplish by how it is written. This sort of obvious code purpose is not always easy to attain. A piece of code out of context may not be immediately clear what it accomplishes, or how it works.

Instead, third way DevOps encourages the use of automated tests as a form of documentation. Any automated test will include a collection of possible inputs, and their valid expected output. This accomplishes the goal of verifying that the component works as intended, but also allows other teams to understand how the code works. Should the original developer be unavailable, a good collection of automated tests will serve as documentation enough. If another team were to want to use the code, they should not need a deep understanding of how the code operates internally. By seeing the input and output for the tests, they should be able to determine if the code would satisfy their needs.