Category Archives: DevOps

DevOpsGuys Launch New Website!

DevOpsGuys launched their new website over the weekend. Our engineers have worked tirelessly over the past six weeks, creating infrastructure, the web application and content for the site.


The site has been designed with simplicity in mind and it gives us a great platform from which to grow. Watch out over the coming week and months as new content is added to the site.

Today we’ve published new pages to represent each of our service offerings: Digital Transformation, Automation, Cloud Operations and Training. These pages are intended to give you an overview of what we do, but they will continue to grow!

You’ll also find information about the great work we’ve done and are doing with our customers and partners. We hope you find this useful.


We’re always happy to hear from you. If you have a suggestion or comment, we’d love to hear it! You could even try out our new Contact Us Page!

DevOps & In-Sourcing guest blog on

We have just published a guest blog on DevOps and In-Sourcing over on the AppDynamics blog – “2016 – the year of Insourcing? #DevOps

The intro sets out the theme of the post:

A lot has been written recently about #DevOps and outsourcing. Some say it will kill outsourcing, others are not so sure. Our view at DevOpsGuys is that the truth is somewhere in the middle but that 2016 will definitely usher in a wave of strategic insourcing rooted in re-drawing the lines between what’s “inside” and “outside” the organisation.

Head over to AppD blog to read the rest and leave your thoughts and comments.

Do you agreed or disagree? How are you bridging the DevOps outsourcing/insourcing divide?

WinOps 2015 update + video + slides

Thanks again to everyone that attended & sponsored the inaugural WinOps conference in London 2 weeks ago.

The feedback has been fantastic so far, with over 90% of the survey reponses rating it as Excellent or Very Good. We’ve had 32 feedback survey responses so we’ve donated 32x£5=£160 to If you haven’t yet completed the survey PLEASE give us your feedback and constructive criticism so we can make sure that we organise an event better event next year. Your survey email should be in your email, if not contact us and we’ll send you one.

If you’ve written up a blog post reviewing the event please let us know and we’ll share it with the group. You can read Hannah’s review here –

If you want to keep in touch with the #WinOps community please:

  1. Join the meetup group –– we’ll have our first meetup next month.
  2. Follow us on Facebook –
  3. Subscribe to the YouTube channel for all the event videos –
  4. Follow the Slideshare channel for event slides –

Don’t forget to support our great Sponsors:

For the start-ups out there Microsoft have asked us to remind you that you can get a lot of MS & Azure love for free by joining their BizSpark programme for start-ups

Are you starting your business? We’ve got the tools to get you started !

Sign-up the Microsoft BizSpark for free !

Microsoft BizSpark provides startups during 3 years the tools to grow and scale your business.

You will have access to the full suite of Microsoft Office to get your business started, Azure credits to host your website, development tools to build you prototype and once you’re ready you can publish your idea immediately to the Windows store!

Get free software, training and support – Developer tools, support and training to build apps & scale your business. Technology to get you in the cloud.

Click here to sign-up to BizSpark  – It’s free. It’s easy to join.

If any questions when you apply, contact our local UK team:

Some other suggestions from MS include:

Thanks again to all the speakers, sponsors and attendees at WinOps 2105 and hope to see you at the Meetups and WinOps 2016!


What does #DevOps mean to the roles of Change & Release managers?

What does #DevOps mean to the roles of Change & Release managers?

One of our team raised this question in our internal #DevOps Slack channel this week and it sparked off an interesting discussion that we thought was worth sharing with a wider audience.

Firstly, let’s start with one of my favourite definitions of DevOps:

“DevOps is just ITIL with 90% of stuff moved to ‘Standard Change’ because we automated the crap out of it” – TheOpsMgr

Now that’s a bit tongue in cheek, obviously, as the scope of DevOps in a CALMS model world is probably wider than just that but it’s not a bad way to start explaining it to someone from a long-term ITIL background.

They (should) know that a Standard Change is:

“Standard Changes are pre-approved changes that are considered relatively low risk, are performed frequently, and follow a documented (and Change Management approved) process.
Think standard, as in, ‘done according to the approved, standard processes.”

If we break that down into the 3 main parts we get:

  • relatively low risk” – DevOps reduces the risks via automation, test-driven development (of application AND infrastructure code), rapid detection of issues via enhanced monitoring and robust rollback.
  • are performed frequently” – this is a key tenet of DevOps… if it’s painful, do it more often, learn to do it better and stop trying to hide the pain away!
  • follow a documented (and Change Management approved) process” – DevOps is about build robust digital supply chains. This is your highly automated, end-to-end process for software development, testing, deployment and support and as part of that we are building in the necessary checks and balances required for compliance to change management processes. It’s just instead of having reams of documentation the automated workflow *IS* the documented process.

This starts to point us in the direction of how the role of the Change & Release Manager will change over time.

In the same way that the role of IT Operations will become more like Process Engineering in a factory the role of Change & Release Management will start to focus on more on the digital supply chain & software production line rather than trying to inspect every single package that flows along that pipeline.

In this way they become more like quality control engineers in that their job becomes to work with the process engineers to design the pipeline in such a way that what comes out the other end meets the quality, risk and compliance criteria to be considered a “Standard Change”.

They also need to move towards more sampling-based, audit-style approach for ensuring that people aren’t skipping steps and gaming the systems.

For example, if the approved process says that all changes must pass automated regression testing they might periodically pick one release and review that the regression suite was actually testing meaningful cases and hadn’t been replaced with a return:true; because no-one could be bothered to keep it up do date.

Similarly, if the process mandates “separation of duties” they could check so see that the person who initiates a change (via the pipeline) isn’t also in the same role required to approve the Jira ticket that Jenkin’s checks to see if that release can be deployed to Live.

The overall goal here is to move towards a “High Trust Culture” but keeping in mind the mantra of “Trust, but Verify” they need to work with DevOps to ensure the appropriate checks and balances.

That, and never, ever invite me to a CAB meeting, ever again. :-)


#DevOps and automating the repayment of technical debt

One of the common things we find in Enterprise organisations looking to move to a DevOps model is high levels of technical debt.

To be more accurate, they are caught in the “vicious cycle of technical debt” to the point that trying to ship anything in a rapid, agile way is nearly impossible. It’s the Greek Debt Crisis level of technical debt.

In many cases layers and layers of process and management have been added into the software development lifecycle in order to try and fix the symptoms of the problem (low quality releases, bugs in production, unstable environments, poor performance etc) but they are just Band-Aids on the underlying issues.

So how do we get out of this death spiral before the organisation can’t compete anymore and a disruptive innovator comes along and eats their lunch?

Well, one trend we see is people looking to DevOps automation to try to create the breathing room they need to break out of this vicious cycle and try to create a virtuous circle instead.


If we can automate some of the routine, error-prone and time-intensive tasks we can leverage that productivity gain and invest that time we’ve freed up into re-paying technical debt.

As we pay back technical debt we get a higher quality, more stable and more agile application, we can then re-invest in more automation to start the next cycle of improvement.

We know that this works because we’ve seen it and done it with clients BUT it comes with a caveat (or two).

Firstly, you need to get commitment from the Product Owner etc that the productivity gains will be spent on paying down technical debt and not on an endless cycle of feature bloat (that was probably one of the causes of the problem in the first place).

I’m not going to wave a magic wand and say that this is easy – it’s not – but if you can find the right analogy (“Technical debt is like walking through quicksand” or “Technical debt is like trying to run a marathon with an 80lb backpack on” or “Technical debt is what start-ups don’t have…”) then you might have a chance.

Secondly, DevOps is more than just A for Automation – it’s Culture-Automation-Lean-Metrics-Sharing (CALMS) – so ideally you’d doing more than just “automate some stuff” and begin to start looking at being “product-centric”, coaching your product owner to understand operational requirements and moving away from the Finance-driven project-centric model.

I’d love to hear some stories from our blog readers about how you’ve paid down technical debt, what your “tech debt repayment model” looks like so please leave some comments or links to your own blog thoughts in the comments below


Redgate Tools – Enabling Continuous Delivery for Database Changes with Octopus Deploy and Teamcity


Great article from our DevOpsGuy – Mani.

Originally posted on Automate thinkable:

I have been recently working with various client around enabling and adopting devops practices within enterprise organisations. It’s interesting to see many people think it’s just code development team and operations have to work together. In reality there is a team who develop/maintain databases which needs to be highlighted to be part of these practices which in my mind is considered as key enabler. To enable these I think we need to have the right tool sets and provide education for the database developers and Database administrators. Earlier I have written article about how you can source control the database and enable continuous deployment using redgate tools. This article is all about how you can do with different tool set combination like if you are already using SSDT and redgate tools works as treat to implement continuous delivery for databases.

Following are the pre-requisites to follow this article

  1. Visual studio…

View original 784 more words

DevOpsGuys @ Agile Cymru


In a flurry of excitement and expectation the DevOpsGuys descended en-mass upon Wales’ first Agile conference in the Wales Millennium Centre last week and we certainly weren’t disappointed.

216 people attended the conference, which featured keynote speakers Kim Morgan and Neil Mullarkey and a variety of interactive sessions from over 30 speakers.

“I was really impressed by how hands-on and interactive the conference was. The sessions and talks were enjoyable and accessible and it’s a real asset for the developing digital scene in Wales for events like this to be taking place. Can’t wait for next year’s conference.”
James Smith, Co-founder, DevOpsGuys

The conference brought a more human dynamic to creating software, living up to the principal of People & Interactions over Processes and tools. James Scrimshire, the man behind the event said:

“By bringing in ideas and thoughts from other industries I think we’ve managed to achieve our goals. Ultimately, the success of the conference was down to everyone who attended and committed themselves to being a part of it.”

 Agile Cymru was the first event of its kind in Wales. As the digital and tech scene in Wales continues to develop we look forward to seeing what the future has in store. Great work Agile Cymru!