From Code to Cloud: Building Resilience Across the DevOps Pipeline

DevOps now manages source code, automation pipelines, CI/CD logic, metadata, and engineering workflows. When these assets become unavailable, entire delivery chains stall — impacting productivity, compliance, and business operations.

Common risks include accidental deletions, misconfigurations, insider actions, platform outages, API limitations, ransomware, and loss of repositories or pipelines. These disruptions can occur even in well-resourced organizations.

Built-in recycle bins and scripts often offer short retention periods, lack metadata coverage, cannot handle cross-platform restores, and fail to meet enterprise security, compliance, or scalability requirements.

Commvault provides unified, cloud-native protection across GitHub, GitLab, Azure DevOps, and more — offering unlimited retention, granular recovery, cross-cloud restores, token rotation, RBAC, audit trails, and scalable cloud storage.

Disruptions can halt engineering productivity, delay software releases, create compliance issues, increase operational risk, and damage reputation — making DevOps resilience essential for business continuity.

Please view video here for a time-stamped transcript

…

Hey everyone, welcome to our session from code to cloud, building resilience across the
DevOps pipeline.

I’m Aashray Agur, Senior Product Manager at Commvault.

This is my third year at Commvault.

I’m based out of Bangalore, India.

In terms of the role, I work with SaaS apps team, directly responsible for Salesforce and
DevOps solutions.

In simple terms, I’m the guy responsible for understanding the needs of the customer and
design meaningful software solutions in this space.

Today our speaker and guest, have Anilkumar from Oikocredit.

Before I hand it over to him, I’d like to speak a bit about Oikocredit.

Oikocredit is one of the largest social impact investors and cooperatives in the world.

They promote sustainable development through investments in financial inclusion,
agriculture, and renewable energy.

They are headquartered in Netherlands.

And Anil is the cloud engineer at

Oikocredit.

to you, Anil.

It would be great if you can talk a bit about your role, where you’re based out of Yeah,
of course.

Yeah, firstly, uh I’m Anil.

I work as a cloud engineer at Oikocredit so I’m based in the Netherlands.

So my focus is uh on implementing, assisting in design and maintaining cloud-based
infrastructure.

The most fun part, the automation process so things can happen faster.

So in short, I make sure our cloud environment runs smooth, secure, and efficient.

Here is the agenda for the session.

We will be starting with the growing risk within DevOps environment, then speak a bit
about why resilience matters, what are the limitations of some of the existing solutions.

Then we move to demonstration.

Over the past couple of years or so, we have seen some of the most trusted names in the
technology space.

faced unexpected issues within their DevOps environments.

For example, a leading collaboration platform lost over 100 plus GitHub repositories.

A global cloud provider had a configuration error that triggered a region-wide DevOps
outage.

Similarly, was an automotive leader saw its key pipelines deleted.

These weren’t isolated cases or security lapses.

They happen to well-resourced, highly mature organizations.

The key point is, this is by no means an exhaustive list.

If you look at these situations, these could have happened to any org.

So what we need to acknowledge is the risks are growing within our DevOps tools.

Why don’t we ask somebody who is in that space, Anil, you’ve been managing DevOps
environments for quite some time now.

When you see incidents like these across the industry, how do you interpret them?

And are you seeing organizations becoming more conscious about protecting their DevOps
environments?

Yeah, that’s a very good question.

So a few years ago, DevOps was mostly seen as a developer workflow.

But today, it’s evolved into something much more.

It is considered part of the business critical infrastructure.

So everyone is focusing most on production systems up and running, but the systems that
build and deliver those applications, the DevOps uh environment are also critical.

So there is a growing awareness uh around the world

to protect this layer, not just from external threats, but also from accidental changes,
insider actions, or even platform outages.

It’s great to see resilience is starting to be built into DevOps from the beginning,
rather than being something that’s added on later.

That’s an excellent point.

Let’s dwell a bit on

why actually resilience matters.

Even before we talk about resilience, let’s take a step back and level set what DevOps
actually means.

Like you said earlier, DevOps was earlier the software development was just two teams
where one team would write the code and the second team, the operations chief job was

about ensuring these systems run.

Now DevOps has

really changed how uh software development happens.

It’s no longer two teams.

Today, everything happens in one continuous loop.

For example, first you start with a plan.

In the plan stage, you think about what features to be built, what new solutions have to
be developed, et cetera.

You may use a solution like Jira, for example, for this.

Then once you plan, then you write the code.

You store this code in a repository and store it in a place like

GitHub, GitLab.

Once you write the code, you package the code and release a build, like an artifact.

After that, you test if everything is good, you deploy your solution, and then monitor.

Once you monitor, then your requirements come.

Then again, you start planning.

You see, this is like an endless loop.

Talk to anyone who has been in the software development space.

Everybody would agree that this would go on and on.

So Anil, why do you think DevOps has become so central to how modern organizations operate
today, especially when it comes to agility and innovation?

Yeah, I believe it’s less about one organization and more about how software delivery has
changed overall.

Nowadays, everyone is about focusing on speed and collaboration.

DevOps really brings development operations and even

security together so ideas can move from a concept to production quickly and reliably.

So, and it’s not just about efficiency anymore.

uh DevOps uh environment now holds most critical stuff like source code, pipeline, uh
business logics, which is basically the organization’s intellectual property and future

roadmap.

So DevOps has become more strategic.

It’s now company have innovate, stay resilient, and also keep a competitive edge.

Exactly.

The ability to move fast, automate, and collaborate across teams has become a competitive
advantage, no doubt about it.

But I also think because of this interconnectedness, so much of interconnectedness, an
issue at one will have

cascading effects down the line.

For example, you lose your code, then everything under that will take a hit.

You know, there are the risks.

Now let’s understand what risks exist today.

We’ve already seen some examples in our first slide what some of the companies
experienced, right?

I’m just trying to put a label for those.

So if there’s a ransomware attack, probably your repos could get encrypted.

In malicious insiders, a bad actor could go ahead and delete your configurations.

In human error, it can be something like uh you and our software developers integrate a
bunch of third-party tools.

If your integration goes wrong, your entire system gets corrupted.

So the risks are there and they’re in our control.

So Anil, from your perspective, what happens if this DevOps pipelines get disrupted even
briefly?

um That’s an interesting one.

So our DevOps pipeline is basically the system that makes sure features and updates for
our internal applications gets delivered smoothly and secure in line with our change

management policies.

So it’s not just about pushing code.

It’s what keeps everything moving forward, testing, integrating, and releasing changes
without any delays.

So if the process gets disrupted even by something small, then it would slow down our
several teams at once.

um And the impact isn’t just a technical.

Our team member needs to feel confident that everything is working as expected so far.

um It’s focusing on mostly fixing the issue and getting things up and running.

So the project.

Don’t lose the momentum.

Got it.

Got it.

I tried to map out uh the immediate risks.

For example, like you said, if you lose something, uh you’ll have deployment delays.

If you use an example test, you’ll have poor product quality.

And today, code hosts your IP.

Today, code is like the heart of your data.

If use that, you’re losing your intellectual property risks.

uh

Beyond the technical side, what kind of business impact would you see if DevOps data
became unavailable in the context of, for example, our corporate data?

Yeah, in that case, uh if DevOps data becomes unavailable even for hours or days, the
biggest uh impact would be the progress.

So when the system that supports software delivery pauses, it slows down updates,
improvements that the team rely on.

That’s why resilience and recovery aren’t optional.

They are built into the process from the start.

It’s more about making sure uh continuity is part of the design.

So even if something goes wrong, we can recover quickly and keep things moving forward.

I mean, I couldn’t have put it any better just to add to what you said.

uh It’s not just the…

data loss rate, you’d be looking at productivity loss.

Potentially, you’d be looking at reputational losses.

If you are in regulated industries, you would be looking at so many compliance gaps.

That’s why resilience has to be built into DevOps by design and agree with the statement,
can’t be enough, that’s all.

Okay, we’ve established that we need resilience in DevOps.

Now let’s discuss a bit about what solutions exist in the market today and what are some
of the limitations with such tools.

Now uh in terms of what solutions exist in the market, uh what I have seen as a product
manager would be some would rely on native tools, the so-called recycle bin.

Some would try some scripts, some custom scripts to oh do the backups and then there are
point solutions.

But,

these have some serious limitations.

Before I talk as a product manager, I’d like to ask you as a customer, why do you think uh
some teams still rely on this native capabilities or scripts?

Why aren’t those solutions not in us?

That’s a very good question.

Yeah, I can speak from my experience.

So we did start by using what was building into the platform and other tools available in
the market.

And those options do not um cover um the extensive options that we are looking for.

And they cover the basics and require high maintenance.

But when you look closer, they often have um shorter retention windows and do not capture
everything that matters like pipelines, boards and metadata.

Got it.

In fact, uh that has been my experience when I uh interviewed with a bunch of folks.

uh recycle bins don’t necessarily cover anything.

Even scripts don’t fully cover something like metadata.

One of the biggest red flags what you see, let’s say you use your scripts would be
security.

Your backups also stay in the same environment.

And that’s a serious uh red flag.

uh If production goes down, your backup also goes down.

So you can’t have backup.

the same environment.

And then you have the auditability issue.

When you use scripts, you don’t see what’s back and what’s going back up.

Lastly, uh the enterprise scale.

Though there are scripts, though there are point solutions, which offer the above three,
uh but they struggle at scale.

uh Probably they can handle hundreds of repos, but when you move on to thousands of repos
or terabytes of data,

they struggle, they collapse under API limits.

And that’s the reason why both scripts and do it like, you know, point solutions cannot
handle enterprise grade requirements.

And this is the gap why Commvault exists in the first place to address these gaps.

Now, before I tell my own solution about why it’s good, I want to hear Anil, as

our customer, what was your biggest driver for using the Commvault solution in first
place?

Yeah, I would say the driver was simplicity and consistency.

Before we were juggling with the different tools, policies for each environment, which
made uh protection complex and harder to manage.

With Commvault backup for DevOps,

We now have one unified approach, one place to see and secure, recover data across DevOps.

And yeah, that consistency also strengthened our security aspect.

um yeah, access control, retention policies are applied in the same way everywhere, which
also reduces risk and helps us staying compliant without adding any extra overhead.

Great, agreed.

In fact, one of the first things what I hear from our customers would be about the single
pane of glass of one place where you could protect all your workloads.

Apart from the ones what you have highlighted, I would like to quickly touch base on two
very important uh points since they are related to my earlier slide.

We spoke about the scale, how many solutions in the market cannot handle large setups.

That’s because of API rate limits.

each of these platforms, Azure DevOps, GitHub, GitHub, you know, these platforms limit how
frequently backups and I mean, how frequently or how many APIs can you use?

Once you those limits, your jobs slow down or they fail.

And we get around that by automatic token rotation.

So backups run in parallel without ever reaching rate limits.

We can take multiple tokens and we rotate it seamlessly.

We also distribute our workloads intelligently so large-scale environments continue to run
smoothly without any intervention.

And the next point uh I’d like to bring in is the cross-platform restore.

We discussed earlier, there can be service outages.

Major players can go down too.

When that happens, when it comes to the rescue, you could move your reports from Azure
DevOps to GitHub, GitHub to GitLab, and in any combination this way,

you are truly resilient, your work doesn’t stop.

And apart from that, we do have all these standard functionalities like you have detail
audit logs, rule-based access control, et cetera.

And at this point, I’d like to take this uh opportunity to also announce we would be soon
starting our support for Jira.

We will be beginning our earlier access program from December.

With Jira, have entered our next phase of development within DevOps, and we’re super
excited uh for our Jira support.

Let’s move on to the next segment of our presentation, the product demo.

This is our Commvault Cloud Console.

This is the single pane of glass through which you can practically protect all your
workloads.

This is the landing page for our DevOps tool.

Let me structure my demo into two segments.

In segment one, I’ll speak about the overview page and how to onboard your app.

In segment two, I’ll focus on the restore.

Overview page gives you a

snapshot of what are applications do you have and what are their sizes.

For example, we haven’t configured Jira, so you don’t see Jira here.

But whatever has been configured, their backup size, how many repos have been protected.

This gives you a sense on how many backups have happened, how many instances for which the
backups haven’t happened.

So this gives you a health check.

Now let’s quickly move on to how to onboard an app.

These are all the apps what we have configured.

uh The summary of this is what you’ve seen in this uh overview page.

Now let’s onboard an app.

Click on Add DevOps app.

uh These are all the four applications what we support.

The onboarding flow is fairly similar for all these platforms.

Click Next.

So app name can be uh anything which will

Let you easily identify it can be on of your Azure DevOps or anything what works for you.

There are two ways you could onboard.

If you use express configuration, it’s Commvault provides the app.

You can bring your own custom configuration.

That means you can bring your own app and use it as well with express configuration.

All it takes is less than a minute to add.

Let’s see how it works.

Bingo.

We have established a connection with this organization.

Now let’s move to Access Node.

Essentially, you have to choose your storage region.

We have presence practically everywhere.

Let’s say if you’re based out of US, you will see US storage region, similarly in Europe,
in Asia.

This will auto show up.

Set up the region.

And then plan.

Under plan, essentially you can

choose uh how frequently you want to backup.

uh We already offer bundled storage, and you also choose retention.

So we offer unlimited retention.

You could run backup starting from once a day.

And lastly, the content.

So these are all the services we protect.

If you don’t want any services to be protected, you could either deselect.

In terms of projects, when you choose all projects, what ends up happening is any new
project or repo which gets created on a day-to-day basis, we scan and we backup.

If, for example, you only want protect or deselect set workloads, could either choose
this.

Since the storage is bundled with license, the preferred practices to choose all projects.

Click on Submit.

Bingo.

Your instance is created.

Now, uh I’d like to touch base on one of the points I kept harping in my presentation,
like the scale.

Why many solutions in the market aren’t handled scale.

That is about uh support for multiple tokens.

Today, we’ve already added app,

which gives you one token.

Now let’s add more.

This was a credential which I’ve already created.

If you want more plus here.

Now what this does is let’s say you hit API rate limits with one, we automatically switch
to second and then third.

This way you could add as many apps as possible.

So uh whenever you hit API rate limits, we switch and then we have this.

That’s how we handle a scale.

With this, we are done with the onboarding part of the demo.

Now let’s see the restore part.

Let’s go back to the organization.

These are all the backups which have happened.

You will see this timestamp.

You could go to any date, click on Restore.

This is the org.

You can click on the org.

These are all the projects.

So the hierarchy is org, projects, and repos.

You could see this has hundreds of projects.

You could go into any of the projects and look at what repos exist.

These are all the repos which exist.

Now, if you, let’s say, want to restore.

Click on the Restore button.

Right.

Now, we offer even more granularity.

Let’s say, for example, you just want to restore artifacts.

You can just deselect.

Or you just only want to restore repos.

You can deselect other services.

That’s how we address the granularity.

And similarly, in-place is obvious.

But we offer restore out of place and even to disk.

This is for your disaster readiness.

Now, let’s look at out of place.

I also spoke about an important factor, right?

Let’s say your platforms can also experience outage.

When you have that, you may want to move your reports to other platforms.

For example, Azure DevOps or GitHub.

And we support that.

For example, you could choose any of the apps configured in the setup.

And this is the arc.

You see, you click Submit.

uh These reports would seamlessly be restored into your app.

GitHub and why with that said so this concludes the oh.

To close the entire discussion, what did we see?

Let’s the reality Cyber incidents are not theoretical.

We have seen companies experiencing it every other day So their risks are very clear the
gap the native tools and do-it-yourself uh Scripts have limitations and point solutions

can’t handle scale.

So relying on them will address your cyber resilience.

And we also discussed the risks.

You’ve been looking at productivity loss, reputational damage, breach of customer trust,
and other possible risks.

The fix, you need to have an enterprise-grade solution like Commvault to address these
risks and be ready.

So I need to conclude for those organizations

that are just beginning to think about protecting their DevOps environments, what advice
would you give them?

Yeah, I would start with by treating DevOps data like any other business critical data.

The other common misconception is that the native tools or quick scripts are enough, but
they might only cover the basic recovery.

They are not designed for long-term assurance, scalability, or even compliance.

So the second one that I want to mention, um aim for simplicity.

So the more fragmented the protection strategy is, the harder it becomes to stay
consistent and secure.

um So we should have a unified approach with visibility, automation, and even strong
access controls.

That makes a huge difference in day-to-day IT operations.

Excellent piece of advice.

Really appreciate your insight.

Before we let you go, use these QR codes to download our DevOps Solution Brief, sign up
for our Cyber Resilience Workshop, take the cyber readiness assessment, and to know more

about our early access programs.

Thank you.