devopsy.kinsta.cloud

Author: Stephen Wilson

  • Don’t Fear, Testing Team! DevOps is here!

    Don’t Fear, Testing Team! DevOps is here!

    I love Gene Kim’s analogy about how all unicorns used to be horses; its  a great visual that I use all the time when encouraging IT organizations to change from thinking “why not” to “why not us” when it comes to starting their DevOps transformation.  If culture is really one of the greatest enemies to faster adoption, then you have to start with where the horses live.

    One of the biggest herd of horses in every organization is the team of people dedicated to testing and validating applications.  Even though these teams are not being included in the conversation, they are in fact the most pivotal part in the transformation.

    A Dangerous Love Triangle

    DevOps is touted as the marriage of development and operations; a match made in heaven.  One small problem though:  in most traditional organizations there is a love triangle between operations, development, and testing, as the flow of bits roll from one team to the other until the application is delivered to production.  With the conversation shifting to how can development and operations work better together the testing teams are being alienated.  The question is where does a testing team fit into this conversation, when the focus is all about bringing development and operations closer together?  How can the testing team assert themselves to help facilitate this transformation?

    Horn Growing Engagement

    The Phoenix Project is a great narrative that introduces robust DevOps concepts.  One cannot go far on devopsy.kinsta.cloud without seeing “The Three Ways” and what they mean.  The first “way” is about getting a really good understanding of the delivery chain and how it works as a whole to deliver applications to the end user.  The team that knows the most about this is the testing team as they are the glue that binds operations and development together. If you are going to start growing a horn, you need to start here.

    Engage with the testing team early and often.  This team knows more about the flow of information from development to production than any other team.  They understand the process of moving applications from development environments, testing them, and delivering them to production. They understand the infrastructure and how it should work and what operations team needs to deploy applications.  This knowledge is the perfect horn-growing fertilizer.

    Performance-Driven Feedback

    In my last post I talked about how performance and change management were two pillars to start building on.  As you start to move from simply understanding the system as a whole and increasing the rate of feedback, performance data is critical.  Remember, in science there is no right or wrong answer – only data that says the outcome is desired or not. Performance data can help take the emotion out of determining whether or not processes are going right or wrong after change is made.  Most of the performance engineering folks are embedded in the testing groups since this type of expertise is needed to drive a successful DevOps transition. However, be careful as you start to utilize these resources as they have the potential to become your biggest constraints.  Protect them and get the mechanics of performance testing and engineering out of their head and into the heads of your development and operations teams.

    Continuous Experimentation

    Once you have the testing team on board and helping in this process an interesting event should occur.  The testing teams will start to embed themselves into Development and Operations.  This is when an environment of experimentation becomes possible, just like in a factory, quality is being tested continuously. This leads to a more combined focus on the task at hand while ensuring the quality of the applications and the speed of delivery.

    So really the phrase should be: DevOps, don’t fear! The testing team is here!

     

  • Don’t let automation be the tail wagging the dog

    Don’t let automation be the tail wagging the dog

    There is quite a bit of talk right now about DevOps and how important automation is.  This could be compared to GM in the 1980s when the company tried to transform the way they built cars through automation and robot.  In the early 1980’s GM spent $90B dollars in an attempt to speed up the way cars were delivered to the market.  This failed with famous stories of robots painting each other and others welding doors shut.  Ultimately this project failed and the robots were scraped.  It was later reported that the money lost on the project could have been spent to acquire both Toyota and Nissan at the time.

    Automation dominates the conversation when it comes to DevOps.  If you do not learn how to build cookbooks you are not doing DevOps.  I fear this is going to set companies trying to transform IT off on the wrong track, focused on the outcome and not on the scientific process to get there.    Alan Sharp-Paul recently wrote that you cannot automate what you don’t understand.  The best way to understand it is in two key ways, change and performance.

    Let Science set you free

    This was the secret that Toyota used to dominate the automobile industry.  They were able to transform all of their employees into little scientist.  Constantly tinkering to squeeze our inefficiencies in the system.  Every worker was empowered to think how things could be done better.

    At the heart of the agile and DevOps processes is the practical application of the scientific method.  Think back to your 8th grade science fairs.  No not the volcanos but the ones that won best of show.  These had a clear hypothesis that stated what they were going to try and prove.  They were able to understand what they were going to change and measure the difference between the before and after.  They could clearly state what changed and if it was a successful experiment or a failure.

    This thinking is key for companies trying to transform to a DevOps IT organization.  If a company does not understand the experiments that are running and what the outcomes should be then automation will just make the problem worse. That is why change management and performance management are foundational for transforming to a DevOps culture.

    Tracking your experiments

    Any good scientist knows exactly what he is working on.  He knows every experiment that is running anticipating the outcome.  He knows all the details about each change that has been made to see how they impact the outcome.  This is the same way that IT should be tracking every change happening.

    Every change done in IT is a scientific experiment running. Tracking every change allows for understanding of the outcome of changes within the application.  Developers and Operations will be more informed about the cause and effect of their changes.  There are multiple different ways that you can track changes but the key is that you are doing it very well before you start to apply automation.

    Measuring the outcome

    There is no need to track the experiments if there are not being measured.  A scientist is very deliberate in how they measure the outcomes.  Good enough just does not get this done.  This is beyond just monitoring.  Monitoring in a lot of cases is after the fact, in production.  This is about measuring the difference for every experiment regardless of where it is being tests.  This creates the need to test changes all the way to when the first functional tests are done, measuring the changes of every code update.  Following it through all of testing and to production.  Understanding how each experiment impacts the system as a whole.

    Efficiency through automation  

    Once there is good understanding of all the experiments and a standard platform for measuring the outcome then automation starts to return exponential benefit.  Because every experiment it known the lower priority ones can be identified and automated.  Risk is better assessed.  Processes can start to speed up because there is visibility and accountability.  Applications are no longer classified as high risk or low risk only change is classified that way.  Determining what can be automated just becomes another experiment that is tried and measured for success and and failure.  Automation becomes just another outcome of DevOps to the business and not the route to achieve it.