One of main principles you and your team capture from DevOps is: You learn continuously from your daily work, and you convert these learnings into reusable global assets for your entire organization.
Use chatrooms to capture and create organizational knowledge. Build bots which are integrated to your chatrooms to quickly perform operational tasks for you. For instance the following message you address to your bot in the chatroom can install FrontEndApp application in TestServer-9 environment, and print the outcome of this command back in the chatroom as if you run the command from your command line interface.
@bot install FrontEndApp TestServer-9
Thanks to this mechanism everyone in your team can quickly synchronize on progress of your work. No information is lost in private instant messages and emails. This nurtures a culture of collaboration and transparency with the work you do. And this is a very effective way to convert local knowledge into organizational learnings.
Last but not least, using common chartrooms speeds up onboarding process of new joiners to your DevOps team or to your company, so they can easily monitor a substantial part of how the work in their teams is performed. You can consider using separate chat rooms for different products, services, components, tools, libraries or integrations, so it will be easier to search and find past activities associated with a certain element in your system.
Instead of putting your knowhow and expertise into documents or Wikis, build executable standards and processes as much as it is possible. One of the best ways to build and share knowledge in your DevOps organization is to create a reusable tool and store it in your code version controlling system, so anyone who needs something like this can find it. When you express a standard and the way you work as executable code instead of static documents which can wrongly and differently interpreted based on who reads it, this code will not only speed up and simplify your business, but it will also support your DevOps organization to pass various audit and compliance checks given that the code has at least a lightweight document which explains how well the code handles the process which requires audit and compliance.
For the work, processes and standards which cannot be automated, create reusable users stories with clear and distinguishable steps and checklist, so everyone in your DevOps organization can reuse and take benefits of such assets. Thanks to these reusable assets, different teams can consistently do similar work. And they improve these assets just like they continuously review, reuse and improve code libraries.
Create ready to use blueprints for components, applications, services and micro-services which handle non-functional requirements built-in by design. In this way, developers will not have to worry about non-functional requirements each time they write a new code.
Furthermore, your organization will have a consistent set of non-functional requirements implemented across your entire application stack. In addition, these built-in implementation of non-functional features will simplify deployment, monitoring, trouble-shooting and operations of software in general while it is in running in test and production platforms. Examples of such non-functional requirements are:
Comprehensive automated testing needs to be part of your coded blueprints. Automated tests clarify purpose of your code, they clarify how to use reusable code most efficiently and they speed up composition of automated tests for your custom applications inherited from reusable code blueprints.
To make sure that all of your learnings and work are shared with everyone, you do not only store source code in your one single repository, but you also store tools for deployment, code to build and execute deployment pipeline, automated tests, code to build and integrate telemetry, standards, tutorials, documents, wikis, helper tools and configuration standards for the platforms.
In this way, all assets are transparently shared with everyone in your DevOps organization. Duplications, multiple versions of same artefacts, components and 3rd party tools are prevented. One repository also enables you to compile, link and build everything at runtime and to use latest version of everything when you develop, test and deploy your software.
If you want everyone in your DevOps team to read, review and fix each other’s code, define your main stream technology standards which everyone in your development and operations teams can learn and work with. What you need is: One compile language, one scripting language and one GUI language. But still let everyone to explore whatever technologies they are interested in, to enable your DevOps team to continuously learn and experiment. How are you ever going to win with your next innovation if you are not exploring and testing at the edges?
In this chapter we summarized for you some of widely accepted DevOps techniques which will enable your DevOps organization to learn and create assets while you are performing your daily work. By leveraging these methods, the cumulative experience and expertise of your entire DevOps organization will backup and empower professional expertise and work quality of each individual in your DevOps team.
Good luck with your DevOps journey!..