Based on Actual Events
For your products to work, what you need is fast, immediate feedback. Stagnating teams that have already accepted failure aren’t going to risk conflict or more failure. Stagnating teams, and lack of feedback, will lead to, well, nothing good.
DevOps exists mainly to shorten feedback cycles. To make that work, you need to deploy something and get it into production as quickly as possible.
When we start the DevOps conversation with clients, we almost always look for opportunities to implement an infrastructure-as-code (IaC) framework.
IaC replaces the old way of managing infrastructure (manual configuration and scripting). Documented step-by-step processes may feel secure. But, that may be simply because they are familiar.
Instead, IaC frameworks create repeatable processes that are more reliable and consistent. IaC also shortens the path to feedback. By automating what was once buggy manual processes with push-button deployment, you also do more to increase collaboration and speed up feature delivery. Everyone reading this should be working in more and more environments that have enabled one-day deployment.
With that in mind, what should a day in the life of a developer in a company like that look like?
Meet Gary*
*Actual Person
Gary is a product engineer. He happens to be a very, very talented product engineer but this isn’t about him, necessarily. It’s about an idea that Gary theoretically brings into work on a very average (and utterly made-up) day here at Sketch.
9 a.m.: Gary comes in with an idea to update the deals screen to include a field to indicate whether the deal was a cross-sell or not. He has a goal of getting that idea to production by 3 p.m...that same day.
After Gary sits down with the product owner, Calvin (also a real person, btw), they mutually agree Gary’s idea is a worthy experiment. Calvin confirms to Gary he wants to see something by mid-morning.
As Gary works on his idea, he also makes sure his code follows the product standard and won’t break once it hits prod. This includes creating a batch of automated tests that validates the functionality of this new feature at different steps.
His code is peer-reviewed to make sure it’s maintainable. Then, Gary kicks off the build in an automated pipeline. The pipeline ran all the tests to make sure there weren’t any regression issues. (There weren’t. Good job, Gary.)
In turn, that paves the way for the quality engineer to review the batch of automated tests created by Gary and sign off on the entire suite of automated tests that everyone already trusts to confirm application stability.
11 a.m.: Gary’s feature is automatically deployed into the staging environment that has automated testing in place. At this stage, it’s ready for another step of review with Calvin.
During the review, Calvin realizes it will be more impactful for the data to be displayed as an icon rather than text. Gary does that to ensure that Calvin gets a chance to see the feature in context with real (but blurred) data. Calvin’s idea is obvious to Gary, so he makes the change. Checking his changes into Git triggers another review by the automated pipeline: The build, the automated tests, and the deployment to the staging environment.
Noon-ish: Gary reviews the tweak with Calvin one more time. With the thumbs-up from Calvin, Gary and Calvin go to lunch.
1 p.m.: Gary triggers the pipeline to deploy the feature to production.
2 p.m.: Calvin is satisfied with the way the feature looks in production (he can see features that others can’t), so he logs into his feature-toggle management console and releases the feature for all users.
Because testing, validating, and deploying were automatic, the team doesn’t have to cross their fingers and hope they don’t start getting a bunch of user tickets because something (somewhere) broke.
Improved Creativity and Collaboration
Beyond the actual speed of the deployment, and the obvious lack of friction and pain for Gary (and other members of the team), what are the other morals of this story?
Improved Creativity
Gary gets to be a craftsperson and problem-solver in this scenario (and his IRL job), empowered to experiment and deliver creative ideas rather than be a glorified order-taker.
Frictionless Collaboration
His collaboration with the PO was relaxed, informal, and productive. The peer review was equally quick and the feedback immediate. Also, because the deployment is automated, Calvin could change his mind that day about the feature, and the world didn’t end. Remember, in our scenario (and this does happen all the time, seriously), Gary had time for lunch and voluntarily ate it with the PO.
Small, Local Deployments
Gary’s automated testing was local, and the deployment included only a single feature.
Bye-Bye Silos
Testing, validating, and deploying are automatic instead of relying on several disconnected departments. The QE signed off on the developer’s tests instead of taking time to write the tests themself. Also, Gary deployed, but Calvin (the PO) still controlled the actual release.
Once You Have The Right Steps In Place, You Never Have To Do It Again
Remember, this story isn’t really about Gary. It’s about what Gary can do. The more any "Gary" on your team can do, the more the entire team can deliver. The sooner they can deliver, the more information you get from your customers and end-users - the very kind of information that can keep you from wasting a bunch of time and money on stuff no one wants or needs.
If you want to learn more about how to spend way less time launching new testing, troubleshooting, and demo environments for your applications (and/or spending way less time debugging the underlying systems), check out our free webinar below!
