Ranger4 DevOps Blog

Happy New Year one and all! Whilst time, or at least the Gregorian calendar, may be a human construct, I do enjoy the annual opportunity for navel gazing and setting intentions for a new dozen of months. I’ll be working with Zen koans daily in 2019 as part of my evolving interests in meditation and the brain. This however, represents my thoughts about the world of DevOps in the coming year, and is also a reflection on my thoughts on the same a year ago.

Our wonderful friends at Sonatype just released the results of their annual DevSecOps survey. For the full results you can download the report. I wrote this article for an ebook where it's collated with a number of other articles from other practitioners - you can download the ebook here.

In 2017, 57% of all participants in the DevSecOps Community survey confirmed that, yes, they did have an open source policy. In 2018 this has risen to 64% - but 35% say they ignore it.

Breaking that down further: in 2018, 58% of those with no DevOps practices and 77% of those with mature DevOps practices reported having an open source policy. 46% of the former and 24% of the latter reported ignoring it. Effectively, that’s then just 12% of organisations with no DevOps practices actually using an open source policy, while 53% with mature practices are following internal regulations. Having, and using, an open source policy is then an indicator of mature DevOps practices.

It's that time of year again! I hope everyone has happy holidays. I've been staring into my crystal ball and thinking about what's been happening in 2017 and these are my thoughts on what the big themes in DevOps are going to be in the year ahead:

1) BizIT: Whilst we are working with many organisations who are facing the classic DevOps challenge of getting development and IT operations to work better together (particularly where new digital transformation departments are accelerating agile adoption), there are many that are achieving the target state of OneIT and the friction they are feeling is more about the business' acceptance of what agile and DevOps really mean in terms of their commitment and involvement in the processes and feedback loops. As we move towards working in value streams, the lines will continue to blur between IT and the business and we'll go from align, past integrate and into 'IT is the business' and beyond where there is no separation. See what the CTO at Hiscox, Jonathan Fletcher, had to say in his talk at the DevOps Enterprise Summit in London this year.

We spend a lot of time talking about change at Ranger4, as you may well imagine, in the context of DevOps. We talk about:

• Increasing throughput and quality simultaneously as a key DevOps goal
• Where Change Approval Boards are a key bottleneck (The Theory of Constraints and The First Way: Flow) - particularly when we are Value Stream Mapping
• What DevOps Target Operating Models look like and how peer-review change works, and what Change Management roles look like

I've been sharing this article, Change Goes Away, a lot in the DevOps Foundation courses we have been delivering in recent months. I love it partly because it's so crisply written but mainly because it's by Rob England, a self-styled IT Skeptic, and who has a primarily IT Operations background. This last part is particularly important since it's often the dev people who want to do away with change, and the IT ops people who want to retain the governance that change management policies and procedures bring - so to have an IT ops person to be such a strong proponent of change changing (!) like this really supports what DevOps is doing here. And gives solid advice on how to manage this potential conflict, together.

Our partner, Sonatype, recently released their latest annual State of the Software Supply Chain report and in it provided new evidence that DevOps practices deliver measurable improvements. It also kickstarted another conversation between us.

One of the things we offer organisations is a free scan of their software to identify a bill of materials (of the open source components within an application) and a summary of the security vulnerabilities and licence risks that exist therein. Applications these days are decreasingly coded and increasingly composed from open source components available in online artifact repositories. It's not difficult to understand why developers would take this approach, as Sonatype's Derek Weeks says:

Yesterday we ran a public version of The Phoenix Project Game to give a bunch of people a feel for how it works and the kind of outcomes they could expect when they run the game with their own teams. If you missed this one but it sounds like something you want to do, we have another one in October; you can register yourself on it here but be warned - the last one booked out super-quick!

Leading IT Analyst, Forrester, just published their The Forrester Wave™: Continuous Delivery And Release Automation, Q3 2017 analysing part of the DevOps toolchain. We know from experience how hard it is for organisations to choose the tools to include in their toolchain and that decisions made today often need to be changed tomorrow as the technology landscape moves so fast. We recently stood up a new LinkedIn group to facilitate discussion around DevOps toolchains as a result of our customers asking us for more help, blueprints and examples of existing toolchains - feel free to join!

Welcome back! We hope everyone's had a wonderful festive break and is fired up to make the most of 2017 whatever excitement and craziness the year ahead is going to throw at us. We're looking forward to helping our customers new and old continue to tread the DevOps path to make our lives (and software!) better, faster and safer. Here are 7 things we're expecting to be working on to that end in the coming year:

Last month Gartner released their 2016 Magic Quadrant for Application Performance Management and for the 7th consecutive year running, Dynatrace were listed as a leader with the highest ability to execute.

Organisations we work with tell us they love using Atlassian tools because the way that they integrate allows them to have traceability through the SDLC - the foundation for The DevOps Loop and end to end ideation to realisation capabilities.

Studies show that organisations that integrate JIRA Software with Bitbucket have fewer status meetings and release an average of 14% faster than teams using a different repository management solution. So HOW do the tools integrate and why does the integration increase velocity and improve productivity?

Atlassian's claim is:

Bitbucket and JIRA Software are seamlessly
integrated, from branch to deployment

Let's have a look at that in a bit more detail and see what it really means.

First off, you can create Bitbucket branches from INSIDE JIRA Software. This helps to give an entire development team context around every branch. JIRA Software automatically populates information for your new branch in Bitbucket and even suggests a branch name based on the issue key. Nice.