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.”
http://itsmtransition.com/2014/03/name-difference-standard-normal-changes-itil/

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. :-)

-TheOpsMgr

#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.

http://technical-debt.org/cycle.png

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

-TheOpsMgr

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

thedevmgr:

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

Agile-Wales-Logo-215

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!

 

 

What does the future of IT Operations look like (in a #DevOps world)?

What does the future of IT Operations look like? As more businesses rely on virtualisation, containers, cloud, Infrastructure as a Service and Microservices is there still a role for IT Operations? How do these teams change to continue to deliver value when supporting Agile Operations techniques?

Is there still a role for IT Operations? Absolutely 100% (we believe that so much we started a company to offer application-centric cloud operations!).

We blogged about this back in 2013 when we said that “Devops Does Not Equal “Developers Managing Production”. We said then:

“Operations is a discipline, with its own patterns & practices, methodologies, models, tools, technology etc. Just because modern cloud hosting makes it easier to deploy servers without having to know one end of a SCSI cable from another doesn’t mean you “know” how to do Operations (just like my knowledge of SQL is enough to find out the information I need to know monitor and manage the environment but a long way from what’s required to develop a complex, high-performing website).” – @TheOpsMgr

This still holds true today.

That said, the role of Operations is changing – Ops has to become more “Application-Centric” and understand the applications that are running on the platforms they provide. It’s not enough anymore to take a narrow view that says “my servers are OK, it’s not my fault the application doesn’t work”. Well, it might not be your “fault” but you share the responsibility for making sure the application is available for your customers. Stop passing the buck!

Operations people almost certainly need to learn to code, since we are heading towards a code-driven, API enabled world.  If you can’t code (or at least have solid scripting skills) you risk being left behind will be left behind.

More importantly, the Operations Engineer/Developer of the future will be filling a role more akin to that of a “process engineer” in a physical factory or logistical supply chain.

A process engineer designs a process and production line that transforms raw materials into a finished product.

The Operations Engineer/Developer of the future will be building Digital Supply Chains and Digital Production Lines.

These Digital Supply Chains will transform raw materials (source code) via continuous integration, test automation, packaging, release automation, infrastructure-as-code etc into applications running in cloud-hosted environments.

The rate of changes flowing along the Digital Supply Chain will far exceed “old school” Change and Release methodologies – you can’t have a weekly CAB (Change Advisory Board) meeting if you’re doing multiple deployments per day (or every 11.6 seconds à la Amazon).

So, just like a physical production line includes statistical sampling, automated testing etc., so will the Digital Supply Chain of the future. We already do this with TDD/BDD, automated testing with tools like Selenium etc but it will become the Operations Engineer/Developer job to ensure that the digital production line delivers release packages of sufficient quality to ensure the stability of the application (and the organisation’s revenue that depends on it!).

Modern supply chains are complex and have many interdependencies on 3rd parties, particularly if you’re operating a “Just-In-Time” (JIT) model. Modern software applications have the ultimate in JIT dependencies due to their integrations with 3rd party SaaS API’s like payment gateways, recommendation engines, authentication gateways, cloud providers etc. Modern Operations Engineers will need to ensure that they design the digital supply chain that can cope with failures in these interdependencies, or at least ensure that they select the right 3rd party partners who can offer the right levels of performance and availability needed for their applications.

In summary, will the Operations Engineer/Developer of the future be “just managing (virtual) servers”? No, almost certainly not.

What they will be doing is designing and building complex digital supply chains with complex interdependencies both internally and externally to the organisation, digital supply chains designed to meet the needs of applications that are designed to meet the needs of their customers, safely, securely and cost-effectively.

The Q&A above is part of material prepared as our contribution to an CA ebook on “Agile Operations”. We wrote our thoughts on 6 questions, of which 4 will be used in the ebook, scheduled to come out in August 2015. You can read the earlier Q&A here – http://blog.devopsguys.com/2015/06/23/what-is-important-for-an-it-ops-to-team-more-effectively-with-preproduction-teams-devops/  

What is important for an IT Ops to team more effectively with preproduction teams? #DevOps

“DevOps can present IT Operations teams with new ‘customers’ in development and test. What traditional or new tools and technologies are most likely to be important for IT Ops to team more effectively with preproduction teams? What information does IT Ops need to pass right to left and which tools are most likely to aid in that?”

The short answer is “A whiteboard marker, a pad of Post-It notes and a couple of pizzas” :-)

That answer is a bit tongue-in-cheek, but there is a serious side to it; whilst new tools can be an important part of DevOps (particularly in Automation) you can get started in changing your Culture and improving your Sharing with very simple tools i.e. the aforementioned whiteboard marker, Post-It notes and pizza.

Start to break down the silos by getting key people in a room with some blank walls and whiteboards and start sharing information, mapping out your value stream and trying to find out, collaboratively, where the bottlenecks in your existing processes are. Once you’ve identified your key constraints then fire up Google and start searching for the tools to solve your problems (or visit a site like DevOpsBookmarks).

DevOpsGuys, like most organisations, have our own “Opinionated Stack” – we like the Atlassian Toolset for managing our Agile workflow, TeamCity or Jenkins as our CI tool of choice, Ansible as our configuration management tool for Linux, Powershell DSC for Windows, AppDynamics as our APM tool, Redgate for our Database Lifecycle Management (DLM) and so on. We partner with many of these companies now because we’ve “dogfooded” the products internally and with our customers and they’ve worked well for our use cases. We always “try before we buy” and we “try before we partner” too because, as they say, “your mileage may vary” (YMMV).

This comes back to fostering a culture of experimentation – give something a try and see what works for you. We started off using Atlassian HipChat as our chat tool and we really liked it. Then we tried Slack and we liked that one more, so we switched. YMMV.

One additional point worth mentioning – the premise of the question is flawed!

They aren’t customers they’re colleagues.

There isn’t a silo of “Us” (IT Ops=supplier) versus “Them” (Everyone Else=customer).

We are supposed to be breaking down these silos to create cross-functional, multi-disciplinary, product-based teams. Development, Test, IT Security, Networks shouldn’t be silos any more – they are people in our team, sitting over the desk from us, attending our daily standups, eating our pizza :-)

The Q&A above is part of material prepared as our contribution to an CA ebook on “Agile Operations”. We wrote our thoughts on 6 questions, of which 4 will be used in the ebook, scheduled to come out in August 2015. We’ll post the remaining 2 questions with our answers onto the blog over the next 2 weeks. 

DOGs at Digital 2015

Digital 2015

Last week the DevOpsGuys headed up to Newport’s Celtic Manor to take part in Digital 2015 – the Welsh Government’s initiative to bring digital innovators and business professionals together. The 2-day event saw more than 2,000 delegates and 140 speakers.

DevOpsGuy co-founder Steve Thair says:

“These initiatives are invaluable to the digital sector because they expose the wide variety of digital and technological services that are available in South Wales to business professionals who can use them to take online business services to the next level. It’s a relaxed environment where people can chat and form connections that will have a direct impact on the future of business and technology in Wales.”

The diverse range of speakers at the event included Microsoft, the WRU, Amazon and the DVLA. The opportunity to discuss the needs of businesses directly with those running them is invaluable. This dialogue can lead to collaborative projects and further development of the burgeoning tech industry in the area.

The team are excited to see more events like this one springing up in the near future. Look out for us at the up-coming Agile Cymru in the Wales Millennium Centre on the 7th and 8th of July.

 

Follow

Get every new post delivered to your Inbox.

Join 3,745 other followers

%d bloggers like this: