Close
  • Latest News
  • Artificial Intelligence
  • Big Data and Analytics
  • Cloud
  • Networking
  • Cybersecurity
  • Applications
  • IT Management
  • Storage
  • Sponsored
  • Mobile
  • Small Business
  • Development
  • Database
  • Servers
  • Android
  • Apple
  • Innovation
  • Blogs
  • PC Hardware
  • Reviews
  • Search Engines
  • Virtualization
Read Down
Sign in
Close
Welcome!Log into your account
Forgot your password?
Read Down
Password recovery
Recover your password
Close
Search
Logo
Logo
  • Latest News
  • Artificial Intelligence
  • Big Data and Analytics
  • Cloud
  • Networking
  • Cybersecurity
  • Applications
  • IT Management
  • Storage
  • Sponsored
  • Mobile
  • Small Business
  • Development
  • Database
  • Servers
  • Android
  • Apple
  • Innovation
  • Blogs
  • PC Hardware
  • Reviews
  • Search Engines
  • Virtualization
More
    Home Development
    • Development

    Why Companies Get DevOps and Continuous Delivery Wrong

    By
    Darryl K. Taft
    -
    August 16, 2016
    Share
    Facebook
    Twitter
    Linkedin

      PrevNext

      1Why Companies Get DevOps and Continuous Delivery Wrong

      1 - 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.

      2Compromising Speed Over Quality

      2 - 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.

      3Testing for Problems at the End of the Lifecycle Only

      3 - 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.

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

      4 - 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.

      5Assuming Your Tools Are Not Compatible

      5 - 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.

      6Not Sharing Testing Expertise and Responsibility

      6 - 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.

      7Mandating the Tools Developers Can Use

      7 - 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.

      8Prioritizing Tools Over People

      8 - 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.

      PrevNext
      Get the Free Newsletter!
      Subscribe to Daily Tech Insider for top news, trends & analysis
      This email address is invalid.
      Get the Free Newsletter!
      Subscribe to Daily Tech Insider for top news, trends & analysis
      This email address is invalid.

      MOST POPULAR ARTICLES

      Latest News

      Zeus Kerravala on Networking: Multicloud, 5G, and...

      James Maguire - December 16, 2022 0
      I spoke with Zeus Kerravala, industry analyst at ZK Research, about the rapid changes in enterprise networking, as tech advances and digital transformation prompt...
      Read more
      Applications

      Datadog President Amit Agarwal on Trends in...

      James Maguire - November 11, 2022 0
      I spoke with Amit Agarwal, President of Datadog, about infrastructure observability, from current trends to key challenges to the future of this rapidly growing...
      Read more
      IT Management

      Intuit’s Nhung Ho on AI for the...

      James Maguire - May 13, 2022 0
      I spoke with Nhung Ho, Vice President of AI at Intuit, about adoption of AI in the small and medium-sized business market, and how...
      Read more
      Cloud

      IGEL CEO Jed Ayres on Edge and...

      James Maguire - June 14, 2022 0
      I spoke with Jed Ayres, CEO of IGEL, about the endpoint sector, and an open source OS for the cloud; we also spoke about...
      Read more
      Applications

      Kyndryl’s Nicolas Sekkaki on Handling AI and...

      James Maguire - November 9, 2022 0
      I spoke with Nicolas Sekkaki, Group Practice Leader for Applications, Data and AI at Kyndryl, about how companies can boost both their AI and...
      Read more
      Logo

      eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site’s focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

      Facebook
      Linkedin
      RSS
      Twitter
      Youtube

      Advertisers

      Advertise with TechnologyAdvice on eWeek and our other IT-focused platforms.

      Advertise with Us

      Menu

      • About eWeek
      • Subscribe to our Newsletter
      • Latest News

      Our Brands

      • Privacy Policy
      • Terms
      • About
      • Contact
      • Advertise
      • Sitemap
      • California – Do Not Sell My Information

      Property of TechnologyAdvice.
      © 2022 TechnologyAdvice. All Rights Reserved

      Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.

      ×