Rawpixel.com - stock.adobe.com
Tips for building a DevOps knowledge-sharing culture
The DevOps spirit of openness and collaboration makes knowledge sharing a necessity. Explore best practices for documenting and communicating knowledge within your organization.
A well-managed DevOps environment captures knowledge in a way that empowers the individual as well as the whole DevOps stream -- and adds distinct value to the business.
DevOps promotes continuous development and delivery through microservices-based composite applications that often share functionalities and automation, which smooths the flow of IT processes. However, when IT staff write application code and automations on an ad hoc basis, organizations risk losing individual team members' knowledge.
Follow these tips to promote collaboration and build a DevOps knowledge-sharing culture that results in better outcomes across the board.
Include the business in DevOps discussions
An environment that encourages collaboration from the outset and provides end-to-end support is a good starting point. This organizational culture must include the business side, not just the IT teams.
To ensure the business is involved, bring in aspects of the Agile development paradigm. In Scrum meetings, IT personnel can brief business representatives and offer them the opportunity to provide input.
The concept of daily Scrums or stand-ups can easily put business personnel off, particularly when the discussion is highly technical. To address this issue, time meetings for when business decisions need to be made, and ensure the business part of the discussion occurs at the beginning of the meeting. Then, let the businesspeople go so that DevOps staff can focus on more technical aspects of the work.
Use DevOps management systems to report progress
Productive Scrums require concise and effective DevOps reporting tools. These tools should provide information on the status of code development, rollouts of operational code and effects on business goals, incorporating everything that happens across the whole DevOps function.
To facilitate reporting, consider adopting a DevOps platform or management system, such as those offered by ServiceNow and Atlassian. These tools can help teams share knowledge and work together, no matter where they're located or their role in the DevOps process.
Store and reuse code, services and automation scripts
After choosing a DevOps platform, ensure DevOps teams can track and share knowledge by capturing and saving code and functionalities. The basic idea is to create an environment where others can find what has already been created, eliminating the need to reinvent the wheel for every function or automation.
Code management and reuse
Code management environments such as GitHub and Bitbucket provide source code management and library functions that can feed into other process-based DevOps tools. Vendors such as Atlassian and Terraform -- along with the cloud providers AWS, Microsoft Azure and Google Cloud -- offer capabilities to build a directory that enables code reuse.
Wherever possible, incentivize developers to make original code reusable and reuse existing code to counterbalance the tendency to believe that their code will be better than a previous developer's. Promoting a knowledge-sharing culture around code cuts down on time and money wasted in duplication of efforts.
Microservices
Effective knowledge transfer for microservices architectures requires a service directory or functional library. There are arguments around which is the better approach, and the two undoubtedly have some fundamental differences. But for the purposes of this article, assume that they are similar enough to discuss together.
A directory of microservices lets developers formally describe and store new code, including details on how to call a service and the outcomes of doing so. Others can then easily search the directory to see if they can use anything that has already been created, rather than writing a new function from scratch.
When choosing a microservice for a new composite application, developers need to know whether future changes might affect their own app's operations. Developers working on microservices that might change substantially in the future must indicate this in the directory to avoid unexpected failures.
Automation scripts
Most DevOps tools on the market offer considerable automation capabilities, but teams might sometimes need a more customized automation script.
Capture these automation scripts, and once they've proven to be solidly replicable, make them available to others who want to carry out the same task or process. The same directory or library function should be able to manage both code and scripts; having two separate systems will not help create an effective DevOps knowledge-sharing environment.
Create and regularly review documentation
DevOps documentation is a necessity, at least at a very basic level. It's impossible to discover code or scripts that do not have any descriptions.
At minimum, documentation for automation scripts and application code should describe the high-level functions they perform. It should also include any inputs required, outputs provided and standards used, such as RESTful APIs or JSON. Providing this information makes such items far more likely to be reused.
Finally, assign a librarian to review the documentation library regularly and identify redundancies in functions or capabilities. The librarian should raise any redundancies with the developers or administrators involved to decide which option is best. In some cases, both might be required, but reducing the number of items in the library will benefit both the DevOps function and the business.
