Should the goals and principles of DevOps be the same for every company? Is it possible for every company to reach CI/CD?
Software delivery teams come in all different shapes and sizes. Each team has its own DNA that has organically evolved through generations of diverse experiences, skill sets, tools, technologies and sets of processes.
So, if every project team looks entirely different than the next, where do you start?
RESERVE YOUR SEAT for this roundtable discussion where we will cover different types of organizational situations and the common as well as unique challenges each situation may face in their DevOps transition. We will review ways to address specific inefficiencies in each situations development process as well as how to plan accordingly and minimize risk along the way.
Date: Wednesday, November 15
Time: 9:00am PT
We will cover:
- How to transition to DevOps and align your development, testing and release processes
- How to plan for your DevOps transition based on your current operational reality
- A breakdown of common as well as unique DevOps obstacles
- A method for systematically resolving your development issues to enable test automation
RESERVE YOUR SEAT and bring your questions for the panelists:
- Tanya Kravtsov is the Director of QA at Audible. She is building a new QA organization to support innovative web product development at scale. Previously, as head of automation and continuous delivery at ROKITT, senior QA manager at Syncsort, and VP at Morgan Stanley, Tanya focused on quality, automation, and DevOps practices, working with internal and external customers to transform development and testing processes. Tanya is passionate about process automation, continuous integration, and continuous delivery. She is a founder of the DevOpsQA NJ Meetup group and a frequent speaker at STAREAST, QUEST, and other conferences and events. Follow her on Twitter @DevOpsQA.
- Bob Crews is the President of Checkpoint Technologies. He is a consultant and trainer with almost three decades of I.T. experience including full life-cycle development involving development, requirements management and software testing. He is also the President of the Tampa Bay Quality Assurance Association. He has consulted and trained for over 200 different organizations in areas such as effectively using automated testing solutions, test planning, implementing automated frameworks and developing practices which ensure the maximum return-on-investment with automated solutions.
Practical steps to shift left
Last month we published “Do you know how much your quality costs?” where we discussed the importance of shifting left and shortening the feedback loop as it relates to the cost of quality. According to Bank of America, discovering a bug in development would cost about 5 hours to fix and $390. Discovering a bug in QA cost about x30. 127 hours to fix, due to to the time it takes to reproduce, the back and forth between dev and QA and the need to trace back the code.. Fixing a bug in production – Estimated at $72,000. Shifting left allows testing close to development as possible and a fast and continuous feedback loop.
Four key ingredients to achieving shift left:
- Test automation – Traditional QA processes would result in months of testing before you get feedback. A productive tester can get about 20 tests done in a single day. Assuming your test suite includes dozens of tests there are two ways to get the feedback loop down to minutes: Hire hundreds of testers or automate your tests. Automated tests don’t get tired, take days off, go out for lunch etc.
- High concurrency – Shifting left means giving near real time feedback i.e minutes. Running dozens of tests, each taking roughly 30-60 seconds, with the expectations of getting the results back in, say 5 min., can only be done if you are running your tests in parallel. The higher your level of parallelism the shorter the feedback loop is. Running your tests in parallel required a grid, a cloud based infrastructure that includes virtual environments allowing you to spin in and out different browsers.
- Build-test-deploy automation – Shifting left means you are optimizing the handover across the different stages of the development process. The development cycle includes dozens of handovers and human intervention can always delay that process hence you want to automate the handover using Continuous Integration (CI) servers. CI servers monitor events through your development cycle, such as a new build, and can be programed to trigger a set of actions once a certain event occurred, such as triggering your automated tests.
- Suites – It is best practice to optimize your quality assurance processes by segmenting your tests into suites and running different suites at different stages of your development cycle. For example you full regression might include thousands of tests. Running all those tests every time a develop push code would be time and resource consuming. If 2-3 key scenarios failed, there is no point in waiting for the entire suite to be over. You might want to create a small subset of tests, composed of your high priority flows, and run that “sanity” suite often, while running the more extensive suites once if sanity suite ran successfully.
Do you how much quality costs? Have you ever calculated it? If you do, you’ll learn that you spend thousands of dollars and hours of productivity on every bug. From the cost of labor, to the cost of deployment, to the cost of finding the bugs in production, no bug fix is free.
Many companies and academics, from IBM to Microsoft to large banks have performed studies to quantify the cost of finding bugs. It’s been well known for many years that the costs go up the closer to production you go, but the actual numbers are a bit staggering.Their findings show the dramatic financial difference between discovering a bug in the wild, and finding it during development.
- Fixing a bug in production – Very expensive. These take time to fix, and while repairs take place, your business experiences pain. Your teams are working around the clock to fix something that also requires your developer to rework something they wrote months ago and forgot about.
- Fixing a bug in QA – Somewhat expensive. The QA person has to report the bug. A senior manager has to determine who to be assigned to this. The developer has to step out of his daily tasks, sometimes impacting the current sprint, attend to the bug, reproduce it, and return to edit some code from the last sprint, which the developer has likely already begun to forget about.
- Fixing a bug in development – Least expensive. takes a few minutes for the developer to fix. If you have an immediate feedback loop, your developer will get feedback minutes after pushing code. If a test fails, it is still within the current sprint and the developer should recognize the code and its implications as everything is still fresh in their mind. The bug didn’t escalate and the likelihood of on time release is much higher.
Shift left is the term coined for a software development cycle that includes a constant and immediate feedback loop. You may have heard stories about how Facebook has put a billion dollars worth of engineering into creating this feedback loop. The company even wrote a PHP-to-C compiler called HipHop to speed up the loading of its test environments.
If Facebook is willing to spend a billion dollars to get that feedback loop, you can spend a few weeks ensuring your own loop is as fast and reliable as possible. This means fast builds, fast test batteries, and short amounts of time between developer compiling, and developer testing.
This requires certain infrastructure that we’ll get to in a future post but organizations that have deployed it, have seen decrease in cost of quality and increase in on-time delivery. You may even have to disassemble your build pipeline to replace a few slower moving items.
Your goal, here, should be one minute or less between build and test. This may seem impossible, or it may already be the way things work for your team. This can require a lot of work, or a little depending on the existing systems. No matter the environment, there is one fundamental truth for all software development: the faster the developer can see their results in a running binary, the faster they can fix problems and the lower the cost of overall quality.
Want to know how to shift left? Stay tuned.