Folks, it’s coming… the biggest delivery of the entire year! In mere days, Santa will deliver all the toys and goodies to kids around the world. Talk about a launch party on Christmas day! But, how is it possible for Santa to deliver all of these quality goods on time, conjuring magic and spreading smiles across the globe? And, what secrets of speed and quality can we learn to make our software delivery a better experience?
Today, Santa’s toy factory in the North Pole is optimized, orchestrated, automated, and continuous. The collaboration and efficient work amongst the elves involved in this SDLC (Santa’s Development Life Cycle) enable them to plan, build, test, and deliver unparalleled joy.
But it wasn’t always this way...
You see, Santa’s factory used to run in a very serial fashion, with a lot of manual elf work, quality checks rushed at the end, and frustrated reindeer waiting to hit the sky. Santa’s stress levels would be through the roof, knowing that they might be missing key features or delivering poor-quality products. After all, it was his name that would be in the headlines if Santa didn’t deliver. It was his name that kids cursed under their breath when they didn’t get that “official Red Ryder, carbine action, two-hundred shot range model air rifle!” (Who can name the movie?)
Nowadays, things work flawlessly. How? By implementing one lean-mean-modern factory machine with elves that implement the tool-chain of Continuous Delivery.
Santa's workshop transformation... from a linear, serial delivery approach to one that is a high-performing, parallel, automated machine.
Top 5 Learnings of Santa’s SDLC Workshop When Implementing Continuous Delivery
Planning, building, testing, and delivering software is very similar to what Santa and his team do. There’s a lot you can learn from Santa’s shop…
1. Adapting to Toy Requirements
Gone are the days when Santa’s elves planned the toy building in silos. They’d pass their requirements on to the QA elves in hand-written sticky notes and excel spreadsheets. But, too often those requirements changed as kids were good some months, then bad the others... so the elves had to adapt. The QA team manually trying to include last-minute adaptations to those changing requirements left way too many dolls sewn incorrectly, footballs that looked more like basketballs, and action figures that were accidently delivered to doll-loving girls—massive problems indeed.
No more. Santa has since implemented software in this part of his factory to automatically ensure that toy delivery requirements change along with the kids’ requests and behaviors—which anyone with kids knows could be every time they see a new commercial! This automated workflow saved all these well-behaved but finicky kids from receiving less-than-the-best gifts, and it saved the QA elves from long sleepless nights toiling away in the workshop.
Your software factory should also be able to adapt to changing user stories and requirements automatically so that quality test cases and test coverage can be adapted on the fly. Did you know that 56% of software defects stem from ambiguous or changing requirements? Tools like CA Agile Requirements Designer help you to be more agile and continuous in your test modeling and test coverage.
2. Getting the Latest Naughty & Nice List Data Whenever Needed
Oh, how this was a big pain for the elves. How can you build the best toys and candy canes if you don’t have access to this type of kid behavior data? The testing elves typically had to send in a request to the gate-keeper elves of this data. For this was real live production data, very sensitive information. You can’t have that PII-type of sensitive info floating around! It was a very tedious process to send in the request, then manually try to take a sub-set of that data, and then mask that data. Sometimes it took weeks to get. But without this data, they might miss the mark meeting the product requirements. Now, they’ve implemented synthetic naughty and nice data creation. They can get access to data whenever they need it to run tests on the toys they are building.
Your software factory should be the same way. You need a solution to take a subset of production data, mask it for sensitive data, and start testing. Better yet, make it automated by synthetically creating fit-for-purpose test data needed for all your new application testing and shave weeks of time off your delivery schedule—and, of course, dramatically improve the quality your users see.
Santa is now sharing his list. How nice!
3. Environment Simulation to Run Toys Tests
Oh the horror! Imagine getting that BB-8 Star Wars droid robot only to find out its head keeps falling off whenever the dog chases it as it rolls down the hall? Or, how about the remote control monster truck that continuously gets stuck in the Arizona sand? It’s not that the elves wanted these issues, but more that they just couldn’t prepare for them. See, they can’t have dogs in the North Pole, as they’d constantly be chasing and biting the elves! And the North Pole doesn’t have sand, so how do you expect them to test for that?! Trying to build these environments would cost way too much. So, they often just settled for the bare minimum or skipped testing altogether. But now they’ve fixed that with virtual simulated environments. Their technologies can mimic the real scenarios that these toys might encounter and they test for scenarios they previously would've skipped over.
Same goes for your software factory. You don’t always have access to production systems, mainframes, or databases. You don’t always have access to APIs or third-party software that you need in order to run tests. You don’t want to pay lots of money to build out physical test environments to test all your software scenarios. That’s where technology like Service Virtualization comes in to save the day, to mimic these environments and systems for you so you can test a lot earlier in the lifecycle.
4. Performance and Integration Testing Bottleneck
Performance testing? Even when the elves had the environments to test, load testing still had to happen. For toys and candy, this meant physically piling them up in Santa’s sled right before the big day to test not only the load weight of the sled overall for the reindeer to pull, but the weight the toys and goodies could withstand before literally breaking under that pile in the sled. This has now been fixed with technology that simulates load right when the toys are built. No broken candy canes or tinker toys anymore. Performance testing is now democratized for even the toy building elves to use (not just stuck with the elves only doing QA sled load testing).
And integration testing? This requires a much higher degree of test orchestration and interoperability between tools to automate tests effectively—ensuring all the parts fit and work together. (And, of course, making sure the batteries are included.) Major integration problems!? Again, all fixed with new technology to test the integrated parts—with the right battery size and power.
Software performance testing and integration testing have also now entered the modern era. Performance testing is now democratized with tools like Selenium, Appium, JMeter, and CA BlazeMeter. Integration testing can be simplified with codeless testing frameworks that enable multiple cross-functional team members to design and execute automated unit, functional, regression, integration, and performance tests covering modern through legacy technologies. Multilayer testing and tool compatibility help complicated modern application tests to be validated across multiple systems, APIs, and services—a continuous testing approach that builds in quality.
5. Orchestrating the Massive Number of Toys to Be Built, Tested, and Delivered
This one was a huge struggle with too many manual steps to get toys from one area to the next in the factory, then onto the sleigh and under the right trees. Poor Reginald (the release elf) was at his wit’s end trying to keep track and communicate status of each toy to the Clauses. Every year it was a battle to deliver by the 24th—an enormous multi-day effort filled with cocoa-fueled drama and Elvin pranks that we really can’t talk about. Mrs. Claus went to work, implementing an end-to-end PRM (Present Release Management) solution for executing a successful continuous delivery strategy. With this powerful automation platform, the elves are able to accelerate and stabilize the toy releases from development through production. No more all-nighters! And Reginald can deliver real-time reports to the Clauses and use the data to improve how they work.
Again, think of the huge efficiencies by implementing an automated release management approach. You get control over your application releases with end-to-end planning, management, and automation of the continuous delivery pipeline. You also get visibility, tracking, and insights for the pipeline so that you can manage the moving parts more effectively, keep stakeholders aligned and optimize processes.
Implementing Continuous Delivery to Create Your Modern Software Factory
Oh, and by the way, these elves who used to work in silos to create, test, and deliver their toys, are now implementing ElfOps for better collaboration. This is implemented within software delivery best practices as DevOps. And every step of Santa’s Delivery Lifecycle is now integrated for better synergies and efficiencies. This is the essence of what has been deemed "The Modern Software Factory." Articles posted at ComputerWorld and DZone have done a great job of outlining the benefits of this new software factory.
Perhaps these best practices in Santa’s Workshop are the best presents for you this coming year. It is time to improve your Continuous Delivery efforts. Make it a point to investigate how you can implement such a tool-chain in your SDLC in 2017.
And don’t forget to thank Santa for giving you this case study by leaving a plateful of freshly baked cookies out on your table on Christmas eve. ;)
Speaking of continuous delivery... that's a lot of deliveries for one night!
And, last request... name the best Christmas movie ever in the comments below. Go!