Skip navigation
All Places > DevTest Community > Blog > Authors decro03

DevTest Community

2 Posts authored by: decro03 Employee

As discussed in my last blog, DevOps:  Problem or Dilemma, it is the competing priorities that are ultimately causing the issues between Development and Operations.  Let’s discuss how to solve those issues, which is what has led us to this strategy called DevOps.

Bringing Development and Operations together with competing priorities can be boiled down to a single concept - Build Trust.  Here are the 3 ways to build trust between Dev (+QA) and Ops.

photo.JPG

  1.  Deliver high quality code to production

Easy to say, but how do we increase our code quality?  Better testing in development.  QA organizations are many times forced to focus on functional testing instead of business requirements testing.  The difference?  When development delivers poor quality code to QA, QA is forced to execute their tests on a limited basis initially, just to make sure the code works.  Working code is not the goal of a QA organization. Their goal is to ensure high quality code that is meeting the business requirements. For example: when a customer is in a promotional period, they are getting the promotional rate; when they are outside of that window, they do not get the promotional rate.  If QA were to focus on just testing the code, they are likely to miss ensuring this business rule is met.  By focusing on the business requirements, QA has the ability to run more tests, more frequently (testing quality in) vs. testing functions with limited scope on an infrequent test basis (testing defects out).  There are numerous ways to address better testing in development, and I will discuss the methods in my next blog post.

 

  2.  Provide visibility and transparency

Visibility into the software development life-cycle (SDLC) for both Development and Operations will help break down the barriers between the teams. With reporting and tracking, teams can answer key questions to measure effectiveness of their tools and process. Focus your metrics around answering questions like:

      • How many changes are required on the development side for a given application that will be moving to production? 
      • What are the defect rates as it moves through the SDLC?
      • Are we seeing significant decline in defect leakage (i.e. reduced number of defects) from one phase of the SDLC to the next? 
      • How are we validating the steps required to deploy the applications throughout the lifecycle? (i.e. stop/start, loading databases, configuring applications, etc.).@

New(er) technologies around Release Automation and Continuous Delivery provide this level of visibility and transparency to all parties.  I will speak in detail about this in a later post.

 

  3.  Develop complimentary, not competing goals

Start with people.  Today, bonus incentives for developers are around amount of functionality delivered to their customers.  Operations personnel are incented on production stability.    These competing goals can completely disconnect the teams.

      • Development should be measured based on their productivity considering both speed and quality.
      • Operations should be measured on stability and time it takes to approve and deliver changes to production. 

To align these goals, find the overlaps such as quality and stability or speed and time to approve/deliver changes.  Give teams goals that have both attributes so that they have a common objective.  By aligning their goals, there is both a need and a team spirit that will naturally help the teams work together.

 

These suggestions for aligning Development and Operations are likely not the only ways to be successful in DevOps but they address the key factors you may not realize are impeding your teams.  By building trust through higher quality code. providing visibility and transparency, and developing complementary goals, teams will undoubtedly find the value in working together.

decro03

DevOps:  Problem or Dilemma?

Posted by decro03 Employee Aug 11, 2014

The definition of a dilemma on dictionary.com is “a situation requiring a choice between equally undesirable alternatives.” Essentially, a situation where compromises need to be made to move forward, not quite as successfully as both sides would like.  The definition of a problem is “an identifiable challenge to which an equally desirable solution can be derived”. Until recently, the competing priorities between Development and Operations teams have been classified as a dilemma.  Let’s dig in:


I spend a lot of my time educating organizations on DevOps and its significance. This topic has been written about, studied and re-written about thousands, if not millions, of times. If there is so much available content, why is it that many organizations still see it as being new? Is this just another industry buzz word for something we have been doing since the beginning of time?  Are Fortune 1000 companies really doing this? Is this only applicable for strictly online companies like Facebook and Etsy? I’m here to tell you it’s real, and Fortune 100, 500 and 1,000 companies are using it. Why? Why all of a sudden is the infusion between Development and Operations so important? 

Both Development and Operations teams have invested significant dollars in technologies and strategies to make themselves more efficient. On the Development side, we have things like Agile Development, Test Automation and Service-Oriented Architectures. On the Operations side, there are tools such as Automated build processes, Configuration Management and Auto Server Provisioning. Despite these capabilities, organizations are not moving forward. Often, individual teams work more quickly, yet the time to market remains the same. The culprit? Competing priorities and a lack of trust.


Development’s main goal is to churn out as many business requirements as quickly as possible to stay ahead of competition. Operations main goal is to keep a stable Production environment. As applications have become more and more complex, we have seen the inverse with quality. Development is pressed to move faster, QA cycles are riddled with defects and compressed schedules. Result? Operations bears the brunt of these problems, as they are typically graded on their ability to keep a stable operating environment. New and updated applications are deployed to production, and they fail. Operations typically deploys these changes over long weekends, so getting the right folks involved quickly is not only a major challenge, it also costs them time on their weekends. So the calluses that the Operations teams have built up over the years have taught them that deploying changes into production is bad, hence they challenge every change going to production.

ron p1.gifron p2.gif

  Therein lies a conundrum: The business wants more functionality faster and a stable production environment. Yet the reality is, more functionality in the timelines the business wants often impacts the stability of the production environment. Dilemma or problem? The emergence of DevOps strategies allows us to classify this as a problem—one that can be resolved without compromising the objectives of Developments or Operation. In my next blog, I will discuss how to bring Development and Operations together to solve this problem.