devopsy.kinsta.cloud

Tag: QA team

  • How to Overcome Resistance to DevOps Implementation

    How to Overcome Resistance to DevOps Implementation

    The number of businesses adopting DevOps to make software releases happen faster without compromising on software quality continues to grow. Within the next five years, the DevOps market is expected to reach almost $13 billion. If you are among those who’ve decided to make a shift to DevOps, you are likely to experience resistance coming from the departments involved in a software development life cycle (SDLC), and even from end users, at the start of your DevOps journey.

    In this article, we will outline the reasons why your employees may resist the DevOps approach and show how to overcome their resistance.

    About DevOps Approach Implementation

    Among the benefits DevOps brings are the fast provision of new infrastructure, quick and reliable delivery of software updates, fewer post-release errors due to the implementation of continuous testing and the alignment of testing and production environments, etc. DevOps implementation requires efforts in establishing tight collaboration between the development, QA and operations teams, as well as adopting new tools and methodologies, such as containerization, IT infrastructure automation, continuous integration and continuous delivery (CI/CD) tools.

    A new approach calls for project managers, developers, infrastructure management, QA and operations teams to leave their comfort zones and get used to new working conditions. However, each stakeholder has reasons to resist DevOps implementation and requires a tailored approach to overcome them.

    The Resistance of Project Managers

    Why They May Resist

    Project managers (PMs) are the first to face the changes when the DevOps approach comes into force. Their resistance originates from a range of new duties, new responsibility and knowledge they need to add to their playbook, such as:

    • Persuading development, QA and operations teams involved in SDLC in the DevOps necessity.
    • Establishing constant collaboration between developers, the QA team and the operations team.
    • Getting familiar with DevOps-specific tools and techniques (CI/CD, continuous monitoring, version control tools, etc.) as well as cloud computing technologies like AWS, Azure, Google Cloud Provider (GCP).

    How to Overcome Resistance

    PMs should become DevOps evangelists as they will be the ones who will contribute the most to overcome the resistance of other parties involved. A CIO should provide a PM with sufficient training on all DevOps-related aspects. Such training should include the management of the development, the QA team and the operations team in the context of close collaboration between them. It should also provide the PM with the understanding of DevOps methodologies and tools–containerization, infrastructure as code (IaC), continuous integration and continuous delivery (CI/CD), cloud technologies, etc.

    The Resistance of Developers

    Why They May Resist

    Developers may resist DevOps adoption due to the following reasons:

    • They are not excited by the necessity to work with infrastructure engineers closer and deal with operational issues if the operations team is not competent enough to address them on their own.
    • They are comfortable with the technology stack they’ve chosen for a particular project and not accustomed to caring about how familiar the other project team members are with these tools and technologies.

    How to Overcome Resistance

    PMs should embrace their soft skills to establish a mutual understanding between developers and infrastructure engineers. They should also make sure infrastructure engineers can work with the tools and technologies developers may use within the DevOps approach, e.g., Docker, Jenkins, by providing them with relevant training.

    The Resistance of a QA Team

    Why They May Resist

    A QA team may feel concerned about a faster SDLC DevOps implementation, since it entails less time for testing. Test engineers now need to acquire new skills prescribed by automation across the entire SDLC. In particular, they face the need to learn new tools for automated testing (Selenium, Appium, fMBT) and API testing (JMeter, Postman).

    How to Overcome Resistance

    To make QA engineers less risk-averse, QA managers in cooperation with PMs, should provide them with appropriate training (tools for automated testing and API testing) and show the advantages DevOps may bring. An opportunity to increase test engineers’ qualification level, less effort on testing activities than required with manual testing are among such benefits.

    The Resistance of an Infrastructure Department Manager

    Why They May Resist

    In the pre-DevOps times, an infrastructure department manager was responsible for controlling the design, configuration and delivery of infrastructure for development, testing and production. With DevOps on board and the IaC approach implemented, the infrastructure manager may feel as if they lose control over the IT infrastructure provisioning and management. What’s more, the scope of the infrastructure manager’s responsibilities extends greatly since they’ll need to run the infrastructure department as a competency center.

    How to Overcome Resistance

    A company’s CIO should explain the infrastructure manager their new responsibilities upfront. The infrastructure manager should stay assured that they change the area of control, not lose it. Within DevOps, the infrastructure department manager has to transform their approach to work. They must be able to help a PM correctly arrange the development, QA and operations team for each particular project taking into account project complexity and size. The infrastructure manager must be able to proactively deal with the cases when the team members involved in software development lack qualification for a project, and not wait until the lack in teams’ competencies results in the project prolongation, for example.

    The Resistance of Operations Engineers

    Why They May Resist

    With DevOps in place, the operations team will have to coordinate their efforts with developers and the QA team from the very beginning of the project, as well as regularly report to the PM on the tasks completed, which is not the usual work approach. To be able to work in the DevOps environment, operations engineers will also have to get familiar with a range of IT automation, version control and other tools. What’s more, the operations staff’s responsibilities will now include the provision of the information on the IT infrastructure functioning to business and technical stakeholders.

    How to Overcome Resistance

    To help an operations team adapt to the DevOps culture, the infrastructure department manager should deliver training to make operations engineers familiar with new tools and technologies they will need to use, e.g., version control systems (Git, Team Foundation Server), software deployment automation tools (Chef, Puppet), etc. A PM, in their turn, will need their soft skills to increase the operations team’s willingness to work in close alignment with development and QA teams.

    The Resistance of End Users

    Why They May Resist

    It may sound surprising, but even the primary beneficiaries of the DevOps approach implementation may resist the changes DevOps brings. There are two reasons for it:

    • The time available for software acceptance testing gets reduced due to a faster SDLC.
    • Acceptance testing becomes automated, and end users hardly trust automated tests.

    How to Overcome Resistance

    To dispel end users’ DevOps-related doubts, PMs must do their best to earn their trust by establishing strong communication with end users. If, for example, end users know software testing covers critical software functionality and the probability of post-release errors is minimized, their confidence in software reliability and the overall trust in the DevOps approach rises.

    In a Nutshell

    Each party involved in software development has its reasons to be suspicious when the DevOps approach is coming on board. New duties, close collaboration, the necessity to apply new tools and other DevOps-related changes may make project managers, developers, QA engineers, IT infrastructure managers, an operations team and even end users resist the new approach.

    To overcome the resistance, a company’s CIO should maintain open communication with each party involved in SDLC, explain their new duties and listen to their concerns. It’s essential to make sure each team member realizes what changes and advantages DevOps brings into SDLC. To ensure they have the necessary knowledge and skills, appropriate training should be provided to project managers, developers, QA team, IT infrastructure manager and the operations team.

    — Andrei Lipnitski

  • Keep Developers Happy and Velocity High

    Keep Developers Happy and Velocity High

    In today’s economy, the companies that prevail are those that can accelerate software delivery and increase developer productivity. Yet, as applications become more complex and codebases grow, companies are forced to implement more comprehensive quality safeguards, which slow the rate at which they can deliver new software. Delivering more incremental builds in shorter intervals can address this conundrum: Customer needs are serviced quicker, overhead for engineers is reduced, and risk is mitigated because changes released into production are smaller.

    That’s why high-velocity engineering teams are applying not only continuous delivery processes but also lessons in experimentation from established leaders including Amazon, Netflix and Facebook. These companies have made experimentation a foundation for their release processes, trying out major feature releases and redesigns within smaller groups before making them broadly available. By using new techniques such as feature flagging, rollouts and traffic splitting, experimentation is no longer just the future for marketing teams; it’s quickly becoming an essential practice for high-performing development teams as well.

    Today, discussions around velocity focus on key practices that developers can use to maximize the effectiveness of continuous delivery, software development and experimentation programs. Here are some key ideas to consider.

    Reducing Your Dependency on a QA Team Actually Makes You Faster (Shifting Left)

    Many organizations eschew the conventional wisdom and deprioritize the heavy lifting of writing comprehensive test suites, opting instead to throw them over the fence to a Quality Assurance team. This approach is almost always less effective and causes organizations to lose momentum instead of conserving it.

    Higher-performing teams actually “shift left” and empower developers to own many parts of the QA process. A solid foundation of tests creates less overhead later on and empowers engineers to release quality code into production faster. Companies can address customer and product needs efficiently, quickly and with more confidence than if they wait for full QA cycles to finish.

    But what if you don’t have the ability (or luxury) to rewrite tens of thousands of tests? The good news is that even without expansive test coverage, you can still take advantage of this approach using code coverage tools. These work by evaluating how much of your codebase gets executed during test runs. If the overall coverage decreases, it means a feature was potentially rushed and is untested and should not be merged into the codebase until the ratio is balanced out. This code-to-test measurement can even “block” code merges unless it meets or exceed the previous threshold.

    Prioritize the Build and Test Frameworks Themselves

    Teams that that prioritize the development of build-and-test frameworks—as opposed to individual tests—are rewarded with faster, more reliable builds. But it’s a struggle to build out reliable processes that can handle tens of thousands of tests in a performant way for each developer.

    Particularly with more complicated test suites, there’s a tendency for these tests to become brittle or prone to occasional failure because of all the moving pieces. Optimizely built a “test gatekeeper” that automatically disables tests that fail in this way, without the need for human intervention, and assigns them to an owner to be fixed. Remember: unreliable tests are sometimes worse than no test at all.

    Achieve Faster Release Cycles Through Experimentation

    Companies that want additional, real-time insights and fine-tuning for their application stack are shifting to feature flagging and feature rollouts to expand their capabilities.

    Feature flags are simple control-flow boolean values that allow developers to use a new, experimental process on their application by gating it behind a virtual on/off switch, and have the option to disable it if a problem is found, all without another code deployment cycle. An example could be a “down for maintenance” notice, or something more advanced like a new product homepage that doesn’t require a code rollout to update the content.

    Feature rollouts take this concept a step closer to real experimentation by placing users into two or more experimentation groups, allowing every new feature to be beta-tested before a full general release. Each new feature becomes an opportunity to run an experiment and collect immediate feedback on your development hypothesis.

    Finally, there’s traffic splitting, a concept similar to feature rollouts that transparently routes a small number of users to a new experimental version to identify any bugs before they reach a broader audience. The primary difference between feature rollouts and traffic splitting is the “all-in” nature of traffic splitting an entire application vs. a single feature.

    Worried that the automated and manual testing of your large product release didn’t catch everything? Send a small percentage of your traffic to the new application as a “canary build” and see what happens. Optimizely experiments with traffic splitting between different production environments (stable versus release candidate, for example) to a small number of users. Facebook, and others have utilized this process for years.

    Shift Left, and Enter a High-Velocity Future

    Thorough testing helps companies catch many issues before they reach customers, but it’s extraordinarily difficult to anticipate every possible usage or scenario for your product. Investing in these release strategies will help companies mitigate the risks of unintended bugs creeping into code or, worse, unwittingly turning their customers into the QA team.

    Our advice? Don’t let feature development take priority over the necessary steps to keep your organization from working lean.  Empower your developers to participate in the process early by shifting left, and watch developer productivity and velocity soar.

    About the Author / Brian Lucas

    Brian Lucas is Senior Software Engineer at Optimizely, responsible for the Build, Test and Release Engineering. Previously, he was CTO at Credible and Hoopla, and lead architect at Sling (Slingbox). He holds four patents. Connect with him on LinkedIn and Twitter.