Why Companies Get DevOps and Continuous Delivery Wrong

 
 
By Darryl K. Taft  |  Posted 2016-08-16
 
 
 
 
 
 
 
 
 
  • Previous
    1 - Why Companies Get DevOps and Continuous Delivery Wrong
    Next

    Why Companies Get DevOps and Continuous Delivery Wrong

    We examine mistakes companies make in their DevOps practices and offer tips for testing, tool selection and information sharing to help fix some of these problems.
  • Previous
    2 - Compromising Speed Over Quality
    Next

    Compromising Speed Over Quality

    In DevOps, it is often the mentality that everything has to happen as quickly as possible. This can mean rushing things out the door with little or no testing. Legacy patterns of multi-day manual testing and multi-week performance test scripting are often cited as the reasons for choosing to "test in production" in place of proactive testing. The myth is that you can't have both speed and quality, but the reality is that equipping dev teams to write their own tests with their own tools changes the game. Committing tests along with code makes near-instantaneous feedback for every build, every deployment candidate possible.
  • Previous
    3 - Testing for Problems at the End of the Lifecycle Only
    Next

    Testing for Problems at the End of the Lifecycle Only

    A common misconception about load testing is that it can only take place at the end of the lifecycle, as traditionally developers had to wait for performance tests to be developed and run by someone else. Waiting until the end of the process to test for performance adds unnecessary drama and surprises. Modern open-source tools and domain specific languages have made developer-driven performance testing possible. Developers who are already taking responsibility for functional tests are beginning to use low-volume performance tests to examine functionality and performance in a single pass, especially with API endpoints. These endpoint tests then become building blocks for automated integration, deployment and post-production tests. 
  • Previous
    4 - Running One Test at a Time, Instead of Many at Once
    Next

    Running One Test at a Time, Instead of Many at Once

    Another common false idea about performance testing is that a test suite must be run sequentially. This goes back to the "nightly build" pattern in which several hours of tests were the norm. It is more efficient to run multiple smaller tests in parallel because the combined test will only take as long as the longest piece takes to run. For example, if you are running 12 tests of three minutes each and three that are four minutes long, running them sequentially will take at least 48 minutes, but running them in parallel will take just four minutes.
  • Previous
    5 - Assuming Your Tools Are Not Compatible
    Next

    Assuming Your Tools Are Not Compatible

    Whether developing a mobile or web app, open-source tools are becoming the norm for developers. Developers tend to have a favorite open-source tool that they use, and they are wary about using other tools that others impose on them. This doesn't need to be a problem, as frameworks are emerging that "play nice" with a wide variety of tools. The key is to have a unified orchestration framework that individual tools can snap into. No matter what tool you use, the process of load testing can be part of a single unified whole without imposing restrictions on tool choice.
  • Previous
    6 - Not Sharing Testing Expertise and Responsibility
    Next

    Not Sharing Testing Expertise and Responsibility

    In today's enterprise, the lines continue to blur between the roles and responsibilities on developer teams; this is especially true as DevOps becomes the norm. In some cases, the testing function can fall to a select few "engineer in test" developers, which limits the ability for tests to be run at all stages in the lifestyle. Ultimately, the ability to test for performance and quality should be a shared function, allowing for many developers to understand and share the same, achievable goal, break down silos that may exist in departments and focus on achieving performance throughout the process, not just at the end.
  • Previous
    7 - Mandating the Tools Developers Can Use
    Next

    Mandating the Tools Developers Can Use

    In large organizations, smaller, self-sufficient teams, rather than large departments are the new norm. When there are minimal interactions between teams, each one can implement DevOps and continuous delivery tools that meet their own needs. Instead of using one companywide set of identical and mandatory tools, teams should be empowered to implement tools and technologies tailored to their own needs. Understanding the process and goals prior to implementing load testing or DevOps tools will ensure project success and better align all teams toward a common goal. Once this understanding is in place, teams can execute in the way best for them, using the open-source tools they are comfortable with that help the team reach its broader goals.
  • Previous
    8 - Prioritizing Tools Over People
    Next

    Prioritizing Tools Over People

    For any technology implementation, but especially DevOps, it is crucial to understand that what will be introduced is a process using the tools—and not the other way around. This means the process and combined requirements of the organization must be understood before trying to fulfill the technical requirements. To do this effectively, all people across the organization, no matter what their role or department, need to be on the same page. To have a fully coordinated approach, one person should be appointed as a continuous delivery engineer, who will take time speaking with each department to understand their needs and coordinate a companywide approach. The continuous delivery engineer will boost visibility into individual needs while also helping develop an overall strategy.
 

DevOps confirmed its place in the enterprise as a must-have for the most innovative companies. Many have adapted a continuous approach to software delivery and development as part of a contemporary DevOps practice. Yet there is much more to the experience than just DevOps, and a lot more to a quality framework than relying on tools alone. While many popular technologies, such as Jenkins CI, Ansible, CruiseControl or Bamboo, can improve a continuous integration strategy, the processes should come first and the tools second. Key to changing a company's process is examining the frequency and scale of tests running throughout the development lifecycle. Let go of legacy thinking about testing as a manual and time-consuming process. Tests are no longer something that slows the process but rather an accelerant that makes moving faster and more confidently the norm. Testing as part of continuous delivery helps identify and fix trouble spots in apps while changes are fresh in developers' minds. After speaking with the technical and management team at BlazeMeter, eWEEK came up with a list of what companies are commonly doing wrong when it comes DevOps—and some remedies.

 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
Rocket Fuel