Continuous deployment is a development concept for software or technology solutions. Instead of building the entire project and then releasing a perfect product at once, continuous deployment focuses on starting with a minimum viable product (MVP) and making regular consistent improvements to it over time.

What’s in it for me?

More controllable costs for development work.

When creating a new product or implementing a custom marketing automation, it can be challenging to predict the timeline for development of each feature. So when we prioritize tasks, and provide regular feedback that includes costs involved, the project owner has greater control over how much time is invested in each aspect. We can set budgets, and then slow down or speed up to stay within budget requirements while also making constant improvements. This means you can allocate funds to your highest priorities first.

Small changes simplify the troubleshooting process.

When you introduce many changes at once, it can be hard to pinpoint which change had what impact. Think about a recipe gone wrong: if you added all the spices at once, it’s tougher to tell which spice threw off the flavor. Similarly, when we’ve made smaller, incremental changes in iteration and encounter a bug, knowing which change caused the bug is significantly easier. The solution to that issue can be reached more quickly.

Getting new offerings to users quickly: a faster return on investment

Let’s be honest, development is an investment. It’s not “cheap” initially. But the goal is often an efficiency for staff (saving them time and you money), or an increase in user engagement (boosting sales and interactions). So the sooner you launch your new offerings, the sooner you see an ROI. When we tighten the loop between development and introduction, you get the results much faster, making the investment even more worthwhile.

Better user experience with a smaller learning curve as users engage with one new feature at a time.

In general, people tend to resist change. This is especially true when interacting with websites or apps they are familiar with. There’s often an uproar when a social media or communication platform releases even a minor update. We humans are creatures of habit. This is why it is easier on the user to introduce one new feature at a time, leaving the rest of the site familiar and in their comfort zone. With small changes over time, you retain trust and engagement.

How to do it right

Dream big and then pare down your MVP

Particularly when starting something new at North UX, we invite our clients to dream BIG. This helps us lay a foundation for where the project could go in the long run. Looking at the big picture helps us see how features will interact with each other in a high-level scope. After we dream big, we streamline. We pare things down to the MVP: what’s the most critical for this project to thrive? Then we pare it down at least one more time. While it can be difficult to truly boil a project down to bare bones, especially when you’re dreaming and envisioning exciting things, taking a continuous development approach really does force us to start with the core essentials and grow from there.

Start where you are at

Not every client starts a project from scratch. In fact, most of our clients come to us with an existing site. The concept of continuous deployment does not have to be implemented from the beginning. It can be picked up and applied where you are right now. We can start “plugging the holes in the boat” to get your current product in a better place. Sometimes, as we do this, we realize we don’t need a whole new replacement. We can create some small changes over time to reach your business goals without re-inventing the wheel.

Maintain a clean codebase

This is critical if you want to be efficient in small iterations. It can be hard to spend money on something that doesn’t seem to yield tangible results from an end user perspective — but occasionally the investment of cleaning up the current code base is well worth it and the best place to start. Think of it like renovating an older home. Often, some renovations today can make sure the home stands strong for years to come. You should be using some type of version control to track the changes overtime, and the current code should be well structured and documented. Creating a working environment that various developers can easily jump into is crucial to continuous deployment, and perhaps the first order of business when adopting this strategy. This ensures you aren’t limited to only using one developer. Any developer on the North UX team (or even a developer from your internal staff!) can jump in and address an issue in a moment.

Think modular

When creating small changes, we can very easily create things in a modular fashion. Modular development is a little like creating a set of LEGO blocks. If you manufacture high-quality LEGOS and create them correctly, you can use those blocks to build a castle today — and then use those same blocks to build a house tomorrow.

When developing module pieces, each aspect can be easily moved and iterated on in various areas of one project, or even carried between projects. This cuts down on future development time. It also separates concerns and potential bugs, and helps in maintaining a predictable, clean codebase. Plus, modular development also allows us to plan well for ongoing changes, knowing what areas of the code base do not need to be touched.

When not to use continuous deployment

Just like almost anything in life, one size does not fit all. There are some instances where continuous deployment is not the right fit for the moment.

One scenario in which continuous deployment is not ideal is when introducing a new design or brand. Doing so in pieces communicates inconsistency and disorganization — not exactly the tone you want to strike when bringing something new to market. Continuous deployment is also not a good fit for rebuilding a new foundation of an existing product. Depending on your current technology, sometimes a foundational change is needed, so small changes over time isn’t practical. Once we’ve replaced the old with the new, we can shift to a continuous deployment approach for the remainder of the project needs.

Interested in learning more about how we can help with continuous deployment? Get started with an ongoing support agreement.