Deliver Fast, Deliver Often: The Hoodoo Way

Everyone wants to do development quickly. “Hurry up and get the thing done.” No one likes a lingering task. But what about when you get the task done? When do you deploy it? Should you wait for a bunch of things to be ready to push out or do you wait for the deployment window?

In the beginning, there was Waterfall. Then came Agile. We are big proponents of the agile method and were instrumental in bringing this about for many companies. But this can be improved upon and has been by other organizations. Nowadays people are talking about Continuous Delivery. The idea of Continuous Delivery is to shorten the Development, QA, and UAT cycles that happen with the earlier methods. The aim is to build, test, and release software with greater speed and frequency. But this isn’t so much an article about these methodologies as it is about how we at Hoodoo Digital try to approach development.

Our preferred method for delivering code is fast and often. It doesn’t always have to be done in massive chunks.

Pros & Cons

Under most methodologies, you would wait for the sprint to end, or some other arbitrary pre-selected release window, before the code could be deployed. This has its pros and cons.

The Pros: There was a prescribed time for work to be done (meaning it couldn’t just drag on forever), and you knew when something would be released so you could plan resources around the event.

The Cons: The prioritization of things to be completed is often determined on what can be done in the time allotted (a kind of sprint point Tetris puzzle), or if something didn’t get done then it had to wait for the next window, occasionally causing several features (possibly unrelated to each other) to get pushed out all at once causing a heavy amount of validation to be done at deployment.

Let me paint a picture of another “con” scenario. You just spent several weeks working on many different features for your Adobe Experience Manager website. You finally get everything completed and ready for deployment. You submit your change request to the Systems team outlining everything. They deploy your code and… something breaks. Now several groups in your company are yelling at you because the site isn’t working. You could blame your QA team for not catching it, but in the end, it’s going to land back in your dev team’s lap to fix. You don’t know which of the numerous items broke the site. Even if you do manage to figure out which one it was, the process to fix things is to revert or remove all of the deployed code, even though everything else you moved live was probably just fine. Now the business users don’t get to use all the new features and they have to wait until the next deployment window (which could be weeks, or possibly months) while you fix the problem and do another deployment. If you had pushed each item out separately then you could have isolated the problem and all the other individual features would still be available to the users while you repaired the bad code.

Exceptions

I assert that smaller and frequent releases are better. But there are certain times when smaller releases don’t make sense. For example, if you are working on a large new feature that has pieces which wouldn’t make sense to be released in isolation; such as updating your AEM instance from Classic UI to Touch UI, or skipping several versions of AEM to put out a brand new site altogether. In these examples, it wouldn’t make sense to do frequent small updates to Production. In fact, it could just break it. But it could work in a lower environment, such as Stage. Let’s talk about this.

If you are working on a large scale project, such as upgrading to the latest version of Adobe Experience Manager or changing from static AEM templates to the new Template Editor tools, then instead of focusing on pushing things out to Production the focus should be on getting things pushed up to Stage. Treat Stage as though it were the Production environment that you and your team are doing continuous delivery to. Let the stakeholders see things as soon as you have them available.

You might argue that your customer or organization won’t have the manpower to review such frequent or smaller items on a regular basis. It’s true, they might not be able to keep up. But that shouldn’t stop your team from pushing up as soon as a feature or ticket is complete. Even if you use a timeboxed method you don’t have to wait until the end of the sprint to get them pushed up to Stage.

How Many Bags Do You Carry At A Time?

It might help to share a metaphor. When you empty your car after shopping, do you grab all the bags and do it in one load or do you take many smaller trips? I think we’ve all been the person who tries to do it all in one load. Your hands can hurt carrying so much, you could throw out your back, you might drop something along the way, or squish something not meant to be squished. You don’t need all that extra baggage in your hands at once. And at some point, you are going to lose capacity or run out of hand space and it is going to become untenable. Better to do it a bit at a time.

Delivering sooner allows you to deliver smaller chunks of code. This means you can more easily find — and fix — issues caused by the release. Then, if you have to walk back the push, you are only losing a small change rather than a large bunch of code/functionality. And let’s face it, this is going to happen at some point because, despite having tested something thoroughly in your Stage environment, there always ends up being some subtle difference between Stage and Production (or does there?).

Sounds good, right? So why wouldn’t someone want to do this? At least one reason is that the process to deploy code is too complex, or perhaps it’s filled with needlessly bureaucratic steps. By no means should you wait until you have a bunch of small things ready to go before pushing them out. If something is ready for deployment, get it pushed out!

If this sounds like something you want to implement for your Adobe Experience Manager practice and you want a partner who has experience guiding organizations to a model that makes all the blocks of Continuous Delivery fit into place, then look no further.

We do. We’re Hoodoo.