Tuesday, July 19, 2022

11 proven DevOps best-practices for continuous improvement

Table Of Contents

    Whether you're about to implement DevOps or searching for ways to make it work better for your team, you must remember that DevOps is all about discipline. There is definitely no magic bullet to doing it right from the outset or to fixing your perceived issues in one fell swoop.

    But you're in luck, because successful DevOps practitioners leave clues and patterns that you can start implementing today to supercharge the value from your DevOps program.

    What are DevOps best practices?

    DevOps is really a set of ideas and practices that emphasise a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

    DevOps best practices that will help you to run your software development projects smoothly. But the list of best practices varies from expert to expert. Here are mine:

    • Maximize collaboration and communication between developers and system operators.
    • Implement a cross-functional approach to building software and deploying it.
    • Make every decision based on whether the outcome helps to improve the product, get it to market faster and deliver it for a lower cost.
    • Fail often, fail fast.
    • Automate everything that you can, right from build, to deployment, to validation, to testing and ideally even commits to production.
    • Measure everything.
    • Set up monitoring and alerts.

    Everything else is just a strategy to achieve the ultimate DevOps goal of continuous improvement.

    Why isn't my DevOps implementation plan working?

    This is an important question to answer for yourself. Beacuse unless you understand the problem, how do you know what to fix?

    Devops does work for some software teams but there are still some teams which fail miserably with trying to implement it.

    You already know that DevOps is a set of tools and methodologies that help software teams deliver faster, better, and cheaper. It is focused on making collaboration between developers and operations engineers (ops) easier, faster, and safer.

    To become successful with DevOps, the first thing you need to do is to break down the silos that currently exist between your development and operations teams.

    But the big problem with the traditional development-operations divide is that it creates a "them-vs-us" mentality among the different groups. Is this happening for you too?

    In fact I've seen this to be a problem in almost all DevOps teams that are tearing their hair out trying to "adopt DevOps."

    Before you implement any of the suggestions below, you will need to get your foundations right.

    How to improve DevOps culture?

    You'll need to ensure that your people understand that DevOps is a cultural revolution wherein the development and operations teams are brought together to build a powerful and agile software delivery system.

    In order to create a solid and scaleable DevOps culture, the traditional roles need to be cast aside.

    To incite this revolution in your own organisation you need to help your people work out how they can collaborate and communicate better. Otherwise there's no way any DevOps best-practice on this planet will help you at this stage.

    I know that's a brutal truth, but before forcing your team to adopt yet another tool or process, work out whether your foundations of communciation and collaboration are solid.

    Once you've done this the good news is that you can start implementing these 10 11 DevOps best-practices with your team from today:

    Idea 1. There is a pattern to DevOps success

    Like most patterns, you will either fall in line or you will try and take shortcuts. Taking shortcuts diminishes you and your teams ability to truly understand, harness and exploit the DevOps' potential to supercharge your business results.

    If you still want to take shortcuts, keep scrolling. Otherwise start implementing these DevOps improvement ideas:

    1. Build solid foundations: identify the processes, people and products that you will use to establish your DevOps practice. Then, agree on how they will communicate and share information and learnings to transform your culture to one that aligns to DevOps principles.
    2. Rationalise your tech stack: reign in your teams' propensity to collect the latest and greatest tools and ask them to decide on those components of their technology stack that are absolutely critical to delivering measurable business outcomes. This is your chance to minimise your tech footprint by refactoring applications to work on common environments and reducing the number of moving parts.
    3. Standardise & share learnings: as individual teams begin to understand how to minimise their tech footprints most effectively, you'll find that they will have built a knowledge base of what works and what doesn't. This is a great time to share these learnings across team and functional boundaries.
    4. Evangelise more key stakeholders: simply by doing the above your teams should be able to commit more to production environments than ever before. This supercharged pace of advancement will some of your testing and security teams feel like they're losing control and drowning, because of which they will create roadblocks. Bring such people into the DevOps fold, share learnings and build trust. This is where you start eliminating every superfluous manual intervention in your delivery process.
    5. Remove infrastructure bottlenecks: you do this by ensuring that your infrastructure configuration and management doesn't become a bottleneck to developer productivity. This is achieved by starting to promote a self-service culture, first by automating infrastructure delivery.
    6. Full automation & self-service: you should now be seeing material benefits in terms of productivity and noticeable improvement in trust, both intra-team and inter-team. Your teams should have self-service system that allow them to continually grow productivity levels and automation that removes bottlenecks.

    You can simply rinse and repeat this template across teams, across divisions and across any functional borders. Follow this pattern and you'll find that your likelihood of achieving the DevOps promised land is boosted because everyone now has a recipe for success.

    A word of caution: be very deliberate when turning manual tasks into automated workflows and build feedback loops to ensure that anything of significance is caught before its absence starts to damage on multiple fronts. Not only is this sound business practice, but also a great way to increase knowledge sharing and collaboration between, otherwise highly protective, stakeholders.

    Idea 2. Cross-team sharing is key to scaling DevOps effectiveness

    Do you have sharing, caring team members?
    We discovered that the foundational practices — the practices with the most significant impact across the entire DevOps evolutionary journey — are dependent on sharing, one of the key pillars of DevOps.
    State Of DevOps Report 2018
    Communication is the key to solving most business challenges. The same goes for IT challenges. So it will not surprise you to learn that sharing and communication is a "key pillar" of DevOps.

    If your teams communicate well internally and externally, then adapting your communication to facilitate cross-team and cross-functional sharing while implementing DevOps will be an easier exercise. You can start with the usual channels for knowledge transfer - ops manuals, mastermind sessions, lunch presentations, etc. The trick is to continue what is working and change that which needs improvement.

    If you know your teams' communication is your Achilles heel, then you could either decide that DevOps is not for you. Or you could your DevOps implementation as a catalyst for fixing this area of your business or department.

    You must buy into the idea that DevOps is just another buzzword, unless you apply it to change the fundamental components of your team and those changes deliver measurable business benefits. Without your complete buy-in, your teams will unable to exploit the non-technical aspects of DevOps to deliver anything other than utter frustration and confusion.

    Idea 3. Start closest to reality & work backwards

    In this instance, "reality" means two things:

    1. Look to start your DevOps journey on a project or with a team where your pain is most visible; and
    2. Also, implement DevOps principles as close to your production environment as possible.

    By doing this you are building DevOps muscles based on reality, not assumption-riddled scenarios that create too much room for doubts and will require modification when you want to use them on production environment. Experience tells us that this is the fastest way to spread the DevOps culture throughout your teams.

    You will know that there is no magic spells to fix culture. But you can start by improving collaboration (and results) from the areas that need this improvement the most. These internal case studies will be key to convincing the remainder of your teams to grow and flex their own DevOps muscles.

    Would you like my team to show you a turnkey application security structure used by top SaaS companies?

    Idea 4. Get DevOps tools that help you shift left with security

    Changing your mindset is not an easy task, yet it is the key to success when implementing this idea.

    Think about this: you're on this DevOps journey because at some point in the recent past you decided and/or agreed that DevOps could really transform the way your team and your business operates. And here you are.

    You have to believe it before you see it.
    Unknown

    You now need this same empowering belief to change your mindset about the importance and place of security within your DevOps practice. You need to believe that its is not only important, but also commercially beneficial to transform the cybersecurity of your applications from an afterthought to a competitive advantage.

    The competitive advantage comes from the fact that enterprises of all sizes want to see enterprise-ready software.

    This is true irrespective of whether these said enterprises are building the software or buying it.

    Achieving this is not easy, because it first requires you to facilitate constant and consistent communication between your ops and security teams. You need to progress mindsets from one where security is about resolving immediate pain to one where it is a key strategic focus that encourages the team to shift left with security.

    Move away from the school of thought that pigeon-holes application security as a tick-box audit exercise and towards one where cybersecurity actively contributes to maximising your bottom line.

    The way to do this is to impelement a DevOps-enabled dynamic automated penetration testing tool, alongside a static code scanner.

    The natural inclination is to want one security tool that does both dynamic and static scanning. While this unicorn does exist, these are very different areas of security and you should seriously think about getting different, specialist static and dynamic vulnerability scanning tools.

    At this point don't forget that an automated vulnerability assessment tool is not enough to maintain a good security posture. It's important to schedule regular penetration testing services from your pen testing provider.

    If you're looking for a turnkey software security structure that is designed for DevOps-enabled teams, you should check out our pentesting-as-as-service (PTaaS) solution.

    As opposed to a traditional web app penetration test services, PTaaS gives you a combination of self-service automation tools, backed up by targeted expert help when you need it.

    Do you want a free trial of a user-friendly, DevOps-enabled vulnerability scanner that helps you ship your software with zero known vulnerabilities?

    Idea 5. Get DevOps tools to automate functional testing

    DevOps without automated software testing is like racing a Ferrari with the handbrake engaged. After interacting with many new DevOps teams, my sense is that many of them are hamstrung by the imagination and risk appetites of their senior leaders, in a classic case of you don't know what you don't know.

    If you don't like my Ferrari analogy, here's a more seasoned that will hopefully help you understand why your mindset around test automation needs to change if you really want to supercharge your DevOps environment:

    DevOps best-practices for continuous improvement
    A ship in the harbour is safe, but that is not what ships are built for.
    John Augustus Shedd

    You've gone down the DevOps fork in the road because you wanted speed and effectiveness. You wanted a competitive edge. Right?

    By sticking to your old software quality habits you are only minimising your ability to achieve all these lofty goals. In short, you're attracting DevOps failure.

    The good news for you is that there are lots of automated software testing tools and testing methodologies that work hand in glove with DevOps teams' needs and desires. It's up to you to select the right testing tool for your organisation and eschew the rabbit-in-headlights approach of simply gravitating to the big brands that are top-of-mind.

    Get our Ultimate Guide To Test Automation for a comparison of the most popular, modern software testing tools and test automation engines.

    Idea 6. Talk to the people at the DevOps coalface

    Senior leadership in large and small organisations often fails to comprehend the nature and scale of the challenges and frustrations faced by those at the coalface. Like many other methodologies, think Agile, Kanban, Scrum, etc, decision-makers are often believe and promote a prettier picture that is reality.

    This disconnect between IT decision makers and their minions is a chilling illustration of the disconnect between senior leadership and their people at the coalface:
    DevOps best-practices for continuous improvement


    While this is human nature and hard to change, mistaking fallacies for the truth will lead to systemic issues that will blow up in your face at the most inopportune times.

    It also leads to undeniable stress and misery for your team, which I'm guessing you REALLY want to avoid:

    DevOps best-practices for continuous improvement


    Your goal is obviously to provide a peak performane environment for your DevOps team by helping them dial down the stress levels.

    Talking to them at regular intervals will help you work out what they actually need. But it's like that their suggestions will fall into some of these ideas, which also double as best-practices for highly effective DevOps teams:

    1. Don't just recruit good people, reward and retain the good people you already have.
    2. Encourage & create multi-disciplinary teams to help build trust.
    3. Help team members find mentors they can trust.
    4. Promote diversity of skills, experience, thoughts and styles within you DevOps teams.
    5. Give them tools that make thier life easier.
    6. Cultivate timely and constructive professional tension to help your team continually raise the bar.

    Point number 6 is a tough on to perfect. But there are real disadvantages to teams where everyone says "yes" and nobody is challenged.

    But once you get this mix right, you'll find that encouraging and harnessing this tension is one of the most underrated advantages of running a DevOps practice.

    The question before you is quite simple: do you just want a good story to promote or do you want DevOps to drive real growth and profits in your business.

    The best way to do the latter is to talk to the people implementing your grand plans to identify and resolve the real issues behind the bottlenecks and inconsistencies that lead to frustrations, resentment and inefficiencies.

    Idea 7. Continuous improvement through continuous integration & continuous delivery

    It's easy to mistake these phrases for meaningless buzzwords. Let me assure you, they are anything but.

    DevOps best practice dictates that you make everything continuous. Right from continuous automated software testing and continuous application and infrastucture security using DevOps-enabled vulnerability scanning tool, like Cyber Chief.

    You MUST have highly (although not "fully") automated pipelines where real people are not required to sit in front a screen to make something happen.

    To accomplish this outcome, you will need to implement high levels of automation using the right DevOps-enabled automation tools. Tools require investment, but they also require planning to ensure that they are used by the right people in the right way.

    Without this level of automation you will not achieve the benefits that you visualised when you set out on your DevOps journey.

    Without this level of automation you are introducing room for failure that will be filled, not because your people are inept, but because as humans we revert to the comfortable and the unknown - even if it produces sub-standard results.

    Be wary of confusing perceptions as reality, because what you perceive as a decision-maker is likely to be very different to what is reality:

    DevSecOps best-practices for continuous improvement


    For this to become reality your teams need to adopt continuous delivery pipelines that run your delivery processes where APIs act as puppet strings.

    This means that your infrastructure needs to be configured for automated deployments; that your software testing tools must be able to be controlled by APIs; and that your security testing tools (DevSecOps software) must have two-way operation and communication through APIs.

    This functionality set in software delivery tools is not a pipe-dream. It's available now. Your job is to find the combination of processes, products and people which allows you to achieve your results.

    You've probably already worked out that the first step to achieving this requires the standardisation of your technology stack.

    This means that you have to force a culture where tools are used because they deliver a real and measurable benefit, not just because they are the lastest fad that someone found on ProductHunt.

    DevOps best-practices for continuous improvement

    Would it help you to have a no-code testing tool to automate all your tests across browsers & devices?

    Idea 8. Make alerting and monitoring automated & configurable

    I know what you're thinking: "here's that A word again!" If you haven't got the picture yet, sit down and make a list of all the manual reporting and monitoring tasks that your teams are still performing. Then work out the low-hanging fruit in terms of what can be automated now and what must be automated later.

    But the "configurable" part of DevOps best-practice is just as important. Without the flexibility to customise monitoring and alerting activities your teams will engage in 2 flights of fancy that will definitely having you pulling your hair out:

    1. Create new monitoring and alerting capabilities that overlap and require lots of maintenance; and
    2. Revert to manual, which will break the system entirely!

    Doing this will help you transition your team from building and relying on someone else to monitor and manage what they've built (in case you haven't already heard, a central team to run DevOps "ops" is bad form!). Amazon's tech innovation czar (and CTO) put it best as early as 2006, when he said:

    DevOps best-practices for continuous improvement
    You build it, you run it.
    Werner Vogels, Amazon CTO

    As your DevOps practice grows you will find manual alerting and monitoring tasks are often the bottlenecks that create the most frustrations and inefficiencies. Alerting and monitoring activities follow a linear growth trajectory alongside your building efforts and at some point they will become a burden on your team's time and your money.

    If you like making data-driven decisions, then this fact should make this best-practice a no-brainer for you to implement:

    DevOps best-practices for continuous improvement


    Idea 9. DevOps automation tools are one of the keys to success, but..

    ...they can also mire you in endless analysis paralysis or overwhelm your DevOps engineers with a bloated tech stack.

    Naturally, your first choice is likely to be between choosing between AWS DevOps or Azure Devops. There is no wrong answer to this riddle. Choose the platform that your team already knows well.

    The decision fatigue sets in when you start trying to chop and change DevOps automation tools further down your tech stack.

    Which tool will you choose for configuration management? Will you use Jenkins or Jenkins + Maven or Circle CI for CI/CD orchestration?

    I've seen teams usually choose the solution that the most senior or vocal team member has used previously. This is not a bad way to start, but remember, you're aiming for continuous improvement and so your team needs to work out if the selected tool really is the best fit.

    It's easy to forget that every new tool adds technical debt that is hard to unwind. So if you are:

    • In the early stages of your DevOps implementation: start with the leanest number of tools you can. Also, agree and document the criteria that you will use to evalue any request to add a tool to your DevOps tech stack.
    • Already deep in your DevOps journey: create a list of every tool that exists up and down your DevOps processes. Conduct a ruthless cull of tools based on current useage, suitability, ease-of-use and scaleability.

    While you're undertaking this work encourage your team to practice their new-found DevOps principles and values of open and constructive communication, collaboration and debate.

    See how all of these DevOps improvment ideas fit together?

    DevOps best-practices for continuous improvement

    Would you like my team to review your DevOps tools & practice like we've done for other fast-growing software teams?

    Idea 10. Make data-driven decisions

    You'll agree that this is one of the most abused buzz-phrases in the tech industry today. But, if this is not second nature to you then you need to take immediate steps to inculcate this into your personal and your team's decision-making process.

    Unlike most other concepts you will read about this year, this is not a fad. Your organisation's performance could be explained by whether you make decisions based on data or pure instincts whims and fancies:
    DevOps best-practices for continuous improvement

    Transitioning to a data-driven decision making culture obviously requires accurate, consistent and timely data. Therefore, it becomes imperative that you and your team has access to relevant dashboards for every element of your DevOps practice. This should be a major consideration when you rationalise your technology stack.

    Learn from the experts about how to transitioning to an evidence-based decision making culture.

    Idea 11. Think, do, analyse, repeat

    DevOps best-practices for continuous improvement
    The way to get started is to quit talking and begin doing.
    Walt Disney

    Follow Mr Disney's advice and avoid the trap of safe and comfortable waterfall thinking. DevOps empowers you to embrace the fail fast motto. Why is this important? Because failure is the step before success.

    This mindset is important if you are going to successfully implement the pattern of success I gave you above. The biggest mistake that I see even experienced professionals making during their transition to DevOps is the propensity to over-engineer their every decision and process.

    DevOps best-practices for continuous improvement
    Don’t worry about failure; you only have to be right once.
    Drew Houston

    Instead run smaller proof-of-value experiments and ingrain this culture of succeeding by failing fast into your team. This is the secret that helps successful leaders scale their outcomes.

    Talk to one of our solution advisors if you need help supercharging your DevOps practice or book a Mastermind session to get your automated software testing and cybersecurity testing purring.

     
    SaaS Brief