How to do Continuous Delivery in your ITIL framework?
Key takeaways ITIL change management framework doesn’t work for frequent software releases That’s a problem because regulated teams want continuous delivery By automating change management they can release software as standard changes Introduction There are quite a lot of articles out there on this topic, usually trying to score for SEO, that promise to show you how to do this without actually ever getting there. But it can be done and in this piece I will explain how.
LATEST ARTICLES
How Merkely automates Change Management for Kubernetes workloads
If you’re delivering software in a regulated space, and you’re using Kubernetes, you’ll know how problematic change management is. On one hand you have a highly dynamic container based system that’s constantly changing. On the other hand regulatory obligations mean you must have a controlled and documented way of managing all of the changes in those systems. And that’s not all. Knowing exactly what’s running in production at any given time is difficult enough, but it’s only half the battle.
My experience of working remotely with our customers
In my previous blog post I described the onboarding experience at Merkely and how I got started with my colleagues in a remote-first company. This time I’d like to take this topic further and talk about working remotely with customers. Making the transition to remote working Before I joined Merkely I spent almost 5 years working as a consultant. At the beginning, when I got my first customer, the idea of working remotely didn’t really cross my mind.
5 reasons why your CI system is a terrible Compliance System of Record
“Why can’t we use our CI system for our Compliance System of Record (CSoR)?” This is a question we get asked a lot when we’re talking about compliance with regulated DevOps teams. And it’s a perfectly reasonable question to ask. If Jenkins, GitLab, GitHub, or CircleCI is the engine for your DevOps it will contain a lot of information relevant to maintaining a CSoR. However, your CI system shouldn’t form the basis for your CSoR and in this article we’ll give you 5 reasons why.
How to design a DevOps Compliance System of Record
If you deliver software in a regulated industry you have to be able to show that you are following a defined process. And that means being able to produce a record of what’s going on in your DevOps workflows. When we have conversations about DevOps compliance with regulated software teams this topic frequently comes up. And what these teams require is best described by Carl Nygard as a Compliance System of Record (CSoR).
How regulated teams can avoid the DevOps Lite trap with DevOps Change Management
DevOps is being adopted across regulated industries, but old ITIL approaches to change management still create unnecessary lead times and risks. Fortunately, you don’t have to fall into the DevOps Lite trap with 20th century change management. Not when DevOps provides all the compliance automation you’ll ever need. 🙌 Technology organizations are moving away from large, monolithic, centrally managed IT systems towards a future with small, loosely coupled and rapidly updated micro-systems.
How to secure your software supply chain with Artifact Binary Provenance
In Merkely, we use Artifact Binary Provenance as the foundation for our audit trails. Artifact Binary Provenance is a fancy term, but the idea behind it is really quite simple. All it means is that we can identify the software we have running in production. Let’s take a closer look 👀 How should we identify software? There’s lots of ways to identify software. In our industry we’ve tried different approaches to version-numbers like semantic versioning and release names.
FEATURES
Visma Tech Talk with Merkely's Mike Long - DevOps: The Beginning of Infinity
In this video Mike speaks to Tinuis Alexander Lystad from Visma about his latest talk, DevOps: The Beginning of Infinity. Inspired by David Deutsch, Mike explores the concept of infinite knowledge creation and how it relates to the future of DevOps. We won’t give away too many spoilers here, so check out the full video if you want to know more. If you want to know more about Mike you can find his profile here.
It’s 2021! Why does Change Management still suck?
There’s an excellent management paper from 2001 called Nobody Ever Gets Credit for Fixing Problems that Never Happened. In it, the researchers looked into how companies create and sustain process improvement. Even though the focus is on Total Quality Management (TQM) and manufacturing processes, the paper contains a ton of useful models for software development organizations. It also helps to explain why the current state of change management still sucks. As the authors pointed out….
The Jan Bosch Interview: The Future for Technology Companies
A few days ago you posted a video from the Software Center about doing continuous testing in regulated, safety critical environments. And it immediately attracted a bunch of objections from people in the comments. Do you remember? Yes, I remember. I think I responded by asking something like “do you have any evidence that testing everything infrequently, and manually, and only at the end of a project is any better than doing fast, automatic, continuous testing?
NEWS
Merkely 2021 - Making friends with change
A lot can happen in a year, and 2021 was no different. We want to help everyone make friends with change and in 2021 we made a few changes ourselves. Hit play on Eye of the Tiger 🐅 and roll the montage…. 1 name change Merkely hasn’t always been Merkely. Back in January we were still called ComplianceDB, the original name chosen by Mike and James when they started the company in 2019.
We're heading to DevOps Con Berlin!
Later this month Mike Long, our CEO, will give a talk on DevOps and Change Management at DevOps Con in Berlin. Here’s a little taste of what you can expect on June 14th. Is it possible to do DevOps in a regulated environment? More specifically, is it possible to practice continuous delivery when we have to track all of our changes and prove that they are in compliance with our process?
What the FCA found when analyzing 1 million production changes
A recent FCA report shows that the financial services industry needs to reimagine its approach to change management. By analyzing data from over 1 million production changes, they found out what works and what doesn’t work in the land of regulated change. Let’s dig in…🕵️♀️ On the 5th of February the Financial Conduct Authority (FCA) published its Implementing Technology Change report. It focuses on the way financial firms manage technology changes and the impact of failures.
TECHNOLOGY
How to do Continuous Delivery in your ITIL framework?
Key takeaways ITIL change management framework doesn’t work for frequent software releases That’s a problem because regulated teams want continuous delivery By automating change management they can release software as standard changes Introduction There are quite a lot of articles out there on this topic, usually trying to score for SEO, that promise to show you how to do this without actually ever getting there. But it can be done and in this piece I will explain how.
Continuous Compliance: A DevOps culture
Imagine your developers are the world’s fastest relay team 🏃 When it comes to build, test, and qualify they get round the running track faster than anyone else. Unfortunately for them the finishing line is hidden somewhere outside the stadium. Welcome to regulated DevOps How did they get to be running this impossible race? Well, better tools and working practices have meant a dramatic shift from annual software releases to a world where teams have the ability to deploy multiple times every day.
Why ITIL Change Management doesn’t work for DevOps teams
Are you trying to do DevOps under regulation? If so, you’ll know the pain of change management. In this article we’ll look at how delivering software with DevOps is incompatible with old school ways of managing change with ITIL and how you can automate your change management process with a DevOps approach. As regulated industries speed up their DevOps processes they find that managing software releases with ITIL tickets and change meetings just doesn’t scale.
