10 Signs You Don't Do Continuous Delivery

While many of these development practices may feel commonplace, if you're doing these, you're not actually doing continuous delivery at all. Read on to learn 10 techniques that can help your team.

1. "Releases" Are Planned in Detail During “Agile” Meetings

Continuous delivery (CD) doesn't mean "intricately plan 12 releases for the entire year." Continuous deployments are never-ending, ongoing, nonstop, and so on. Agile was something dev teams aspired to achieve 10 years ago when monthly release cycles were considered valuable. Today, daily production deployments have become the norm. All the planning, meetings, approvals, tickets, and general politics associated with managing releases will actually slow you down or kill your business in today's world. 

In the year 2022, you don't want to be riding a horse when all of your competitors are driving cars.

2. You Don't Commit to Trunk

Branch, commit, merge,resolve conflicts – all tasks that slow you down. The whole point of CD is to deliver and deploy independent software components fast and frequently using dev teams that work in parallel.

If a build, test, or deployment pipeline fails, you should stop, understand what happened, fix it, and learn from it. This is what happens in production, so why not during development and testing? Committing to Trunk will drive the right team behavior and urgency required for CD.

3. Fixing Builds/Deployments takes 30+ mins

The whole point of a deployment pipeline is to kill your build before it causes production outages. When a deployment pipeline or test fails, it should be treated as a "stop-the-world" event where everyone stops, focuses, and fixes the build so things can progress. If your production canary or deployment fails, you should be able to roll back instantly or roll forward with a rapid fix.

We practice rapid rollbacks at Harness today. Bugs discovered by Harness are been fixed in minutes, not hours. Once, a bug was reported at 8:45am, and one engineer fixed the bug minutes later on her Caltrain journey to work. Shortly afterward, another developer pushed the fix while riding BART using his smartphone. 

4. Deployment Pipelines Take Hours to Complete

Let's imagine your new build or artifact is perfect. How long does it take for that artifact to be promoted through all your deployment pipeline stages (Dev, QA, Staging) and into production? One hour? Two hours? Six hours? Longer?

Feedback loops for deployment pipelines (and stages) need to happen in minutes, not hours. This may require more test/tool/feedback automation so you can eliminate manual tasks and approvals throughout your deployment pipelines. For example, if one pipeline stage succeeds, it should automatically move on to the next until a stage fails.

5. Your Deployments Rarely Fail in Testing

If 95% or your deployments succeed in dev/QA/staging, something is very wrong. Your deployment pipelines either lack basic test coverage or they lack integration with your existing toolsets. If you've already invested significant money in tools, why aren't you integrating and leveraging them to gain insight into your pipelines?

For example, many of our customers leverage APM (AppDynamics, New Relic, Dynatrace, etc.) and log analytics (Splunk, ELK, Sumo Logic, etc.) to help identify performance or quality regression in deployments. We call this continuous verification at Harness.

6. It Takes a Village to Deploy and Debug 

It's entirely possible you've automated your deployment process. By automated, I mean you've stitched together deployment scripts written by 20 different people, who, at some stage, tweaked and refactored a few hundred lines here and there.

So, when something breaks, it literally takes a village to debug and troubleshoot a deployment. We had one customer who described their previous deployment process as a "village exercise" that took 15 people six hours to debug.

Next time you deploy, count the number of people involved and multiply that number by how long the deployment process lasts. Village deployments are expensive and time consuming.

7. You Have a Dedicated Deployment/Release team

If you have multiple devs or product teams, the last thing you need is another team that bottlenecks all your deployments. Tickets, change control, approvals, handoff, documentation, and so on are more activities that slow down your deployment timelines.

If a deployment/release team does multiple deployments a day and the first deployment goes wrong, then they'll probably spend the next six hours debugging versus deploying, and thus bottlenecking other deployment pipelines. This just slows down your team’s ability to meet customer demands.

8. Developers Don't Deploy/Debug Their Own Code

Most well-oiled CI/CD organizations have their DevOps teams build deployment pipelines to use during deployment. Let me say that again: DevOps manages the tooling/automation/framework and developers use this platform-as-a-service so they can deploy their own code. We call this CD-as-a-Service at Harness.

When you let developers deploy their own code something natural happens:they end up debugging their own code should something fail. This is a very good thing. If code fails in production, then you need the right set of eyes, context, and knowledge to rapidly troubleshoot. You also need the ability to automatically roll back if you can't roll forward.

We hear too often from customers that Deployment/Release teams often drag DevOps or SREs teams into firefights when deployments go south.

9. You Don't Know the Business Impact of Deployments

The whole reason for doing CI/CD isn't so you can spend a ton of money on people, technology, and tools. You do it to grow your business and make it more competitive.

Organizations adopt CI/CD so their applications and services deliver a better service and experience than their competitors. End of story.

Let's imagine you spend $1 million a month on a new service for your business, and your team does daily production deployments. Do you know what positive impact each of those deployments had on your business? More importantly, do you know whether any deployments had a negative impact? If so, by how much? As Winston Churchill said, "No matter the strategy, it's always good to occasionally look at the results."

10. You think DevOps is CD

It's not. DevOps is a culture or mindset, whereas CD is a practice or set of principles that teams follow to deliver software safely, quickly, and in a sustainable manner. A DevOps culture makes CD principles easier to implement, but it's not going to magically re-architect your application so more components can be deployed more frequently in the cloud.

The vast majority of Harness customers are migrating from "vintage" monolithic applications to cloud-native microservices. CI/CD is a core initiative that is helping them make that transition. DevOps is a popular initiative, but this is more about people, culture, transparency, and collaboration across teams. It's not about tools or technology.

Adopt CD with Harness

These are 10 of the most common signs we see that indicate an organization isn’t properly utilizing CD. What other mistakes do you see other teams making?

If you’d like to hear more about how Harness can help your team implement CD, sign up for a free demo today!