Throughout my career, I have had many opportunities to see how individuals, teams and entire companies can benefit from best practices. However, I have also seen some examples where there have been missed opportunities to do things right.
One challenge that software development companies face is that developers and some of the higher-level positions – such as architect, quality assurance (QA) and project manager – can be stuck in silos. DevOps really helps here, in that it creates a unified set of tools for communicating how development is progressing.
Below are nine tips for how to do DevOps right, ensuring faster responses to client needs, increased developer confidence and achieving client goals.
Embrace Automation. The key to DevOps is automation – that’s what really drives efficiencies. Without human intervention, things just happen on their own, and you basically remove any lag time. With manual mistakes removed, processes are faster and more reliable.
Incorporate Rigorous Testing. At Simpat Tech, where I’m CEO and founder, we make it a policy to incorporate frequent automated testing with our developers. Within our DevOps process, tests are run every single time a new piece of code has been added. If something’s been built that has a negative impact in another area, then the tests will fail. This influences the entire build process. Our developers can’t move that build anywhere – into any environment – if the code has failed a test. With this automated best practice, we catch things early, with a significant reduction in code defects.
Have a Master Plan. It’s useful to make the effort to have a master plan. Without a plan, a team is just building as they go, and an organization can be exposed to avoidable risks, such as possible errors in workflow or building something that isn’t scalable. In this context, it’s important to get a handle on what kinds of manual interventions might still be needed.
Put Project Management Tools Under the DevOps Umbrella. At Simpat Tech we use JIRA as an integrated project management tool. With JIRA, a business analyst creates a ticket, which is associated with a feature, as well as requirements and acceptance criteria. The ticket is assigned to a developer, with GIT as a source code repository. When the developer is done, a pull request is created for another developer to review the work. The project manager has access to all the source code changes, and once the second developer has approved the code, it merges with the main repository. From here, it automatically deploys into the test environment and QA. If there are problems, it goes back. If not, the end user can accept the features. The common thread here is that the right project management tool can function as a “one stop shop”. Everything can be integrated, with the workflow moving through different responsibilities.
Avoid Email. In organizations that get the most out of DevOps, there is almost zero communication by email. This is true of Simpat Tech, too, where communication is done within the tools. In JIRA, for example, all of the questions and answers with QA and business analysts are logged as comments on the ticket. This creates full transparency – it’s all there. As well, code changes can be done through a repository platform. Business communication platforms like Slack, which we use, can also help.
Commit to Short Release Cycles. One of the great advantages of DevOps is that it allows an organization to put software into production much faster and to commit to tighter release cycles. Builds can be deployed every other week, or once a week – as opposed to once a year. This allows for more immediate responses to feature requests. Fewer changes are introduced with each iteration, which reduces risk and puts less burden on the QA team. It also makes it easier to respond quickly when incompatibilities might be introduced in the larger tech ecosystem, such as with browser or other software upgrades.
Incorporate DevOps Into Agile. The Agile methodology works hand-in-hand with DevOps. Part of the Agile framework is to have a retrospective. This is a time when everyone comes together without judgement and talks about what can be learned from the last sprint and what can be done better. During the retrospective, it’s important to have DevOps representation, which should be included in any plan. By coordinating DevOps input, and allocating time to make DevOps improvements, an organization can commit to continuous improvement.
Support a Culture of Respect for the DevOps Team. In the past, I have seen instances where DevOps is looked down upon. Things were magically changing behind the scenes – yet not everyone was aware why. All project stakeholders should understand how DevOps contributes to success. This will result in a tolerance, and even respect, for DevOps’s commitment to automated change notifications. In fact, it’s wise to set a precedent wherein there is cultural support for over-communication. This not only ensures that gaps are bridged, with everyone receiving ample notifications, but also that teams fully understand the importance of DevOps.
Be Proactive. The DevOps side needs to be given the time to research and understand new technologies, so that they can be proactive. For example, typically these days we are managing cloud environments, which are changing every day. There are also situations where clients are relying on legacy technologies that are reliant on resources with a set time frame. It is really up to DevOps to understand the timeline for retiring such resources.
Quality software isn’t developed by accident. By embracing automation and testing, committing to a solid plan, being proactive, utilizing effective project management software and embracing short development cycles, an organization can maximize the benefits of DevOps. These approaches, as well as support for the DevOps culture and incorporation of DevOps into the Agile methodology, ensure that DevOps is done right and go a long way to guaranteeing a successful outcome.