devopsy.kinsta.cloud

Tag: continuous delivery

Perforce: The biggest little secret in DevOps
Quick can you name a company that is 15 years old, never took a dime of venture money, has over 250 employees, over 10,000 customers and was widely profitable from day one? Until last week me neither. That was when I was briefed by Dhruv Gupta, Director, Product Marketing and Bob Dever, Director, Corporate Marketing for Perforce.

Perforce is a DevOps powerhouse. Take a look at the customer cloud to the right to get an idea of who some of the 10,000+ customers they have are. Perforce is all about version control. They do that and do it well. Whether you are talking about version control of your code, documents or analytics, Perforce has a solution for you.

When you think about it, you can see why Perforce is such a DevOps play. DevOps is all about continuous delivery or at least rapid release. How can you accelerate your releases without keeping track of the different versions? Without version control you quickly have a mess. Perforce has in some ways enabled continuous delivery and rapid iteration. They truly are the biggest, little secret in DevOps.

For many years Perforce was really the only choice in town for version control (there were others, but it became a leader in the space pretty quickly) but the rise of GIT, a distributed version control system (DVCS) gave some an alternative. But GIT lacked the enterprise features (read security and team management) that larger organizations needed. Its popularity among lone wolf and smaller dev teams though was unmistakable. It is easy.

Perforce has recognized this and has just released a new hybrid version of their solution. This hybrid version allows developers and dev team managers to use GIT and Perforce’s P4 in one hybrid version control platform. A best of both world solutions give DevOps teams the ability to move fast with GIT and have the security and enterprise functionality that P4 allows.

When you start thinking about DevOps Unicorns like Netflix for instance or Salesforce, the sheer magnitude of what Perforce is managing comes into clarity. In Salesforce for instance you have 3,000 Engineers making 4,000 – 9,000 Code Changes a day with 550,000 Tests / Hour. Keeping versions straight is not the kind of thing you do in a spread sheet.

It in a Continuous Delivery environment where Perforce really shines. They are making a big bet on enterprises adopting the Continuous Delivery model. However there are some fundamental questions to answer first. According to Perforce though you need to define what does Continuous Delivery mean to you? They conducted a survey:

According to Perforce they think of Continuous Delivery as this:
- Deliver working product to users as quickly as possible
- Every change (check-in) leads to a potential release
- Give business the option to release – what, when, to whom
- A change in process and culture
Most importantly though, Continuous Delivery is not just something Perforce thinks is crucial. Waterfall release models are obsolete and even Agile is just a way stop towards Continuous.

According to Perforce’s own survey they see Continous Delivery attaining critical mass:

Is this a case of when you are a hammer everything is a nail or are we at the dawn of the age of Continuous Delivery? Perforce is making a bet that it is. They are already very successful, any more and they may just lose their status as the biggest, little secret in DevOps.
March 18, 2014
DEVOPS AND CONTINUIOUS DELIVERY; THE NEED FOR SPEED

Some good stuff around the DevOps scene this week on DevOps and Continuous Delivery, which the pundits are saying will be a major spend area in 2014.

First up is the Devopsguys who with a little commentary reposted this infographic from Zend Technologies. It demonstrates the real value in DevOps and continuous delivery. One thing that jumped out at me was that according to the data, ninety- nine percent of the Companies surveyed are now recognizing a greater need for DevOps strategies than before. Zend built the graphic utilizing data from various credible industry sources.

Of course you can’t talk about Continuous Delivery without at least mentioning Jez Humble, after all he literally wrote the book on it. He recently posted on his blog four visualizations by Nhan Ngo, a QA Engineer at Spotify. The four visualizations were created while reading Jez’ book, Continuous Delivery. Some pretty intense stuff. Nhan Ngo made it look almost simple, almost like like a comic strip, but there is nothing funny about it.

If you really want to get into the trenches, here is an interesting video that I found called Continuous Delivery and Zero Downtime from the site Night Hacking. The scenario is your “Continuous Integration system is well oiled and kicks in after every commit. Your code is compiled. Your tests are green. You feel ready to take your project to the next level and move to Continuous Delivery.”

We aren’t done with our look at DevOps and Continuous Delivery just yet, DevOps Reactions probably illustrates best how Continuous Delivery works. It works in the model, but in the real world it requires real skill.

If you would like something mentioned here or have something you think I should Shout Out; email parker@devops.com and don’t forget to comment here.

March 18, 2014
Always-on: The New Normal

One of the many challenges of DevOps is finding great team members that can handle the always-on nature of the job. Nearly everyone at VictorOps has been “that person” and has done the weeklong stint of carrying the virtual pager.

What we noticed in our years of doing that job is that team member behavior tends to be polarized. If it’s your week to be on-call, then you are “all in”. You don’t venture far from home, you can’t attend special events and you have to apologize to your significant other a lot. When you are not on-call, you tend to unplug from the company. These are normal behaviors and completely understandable given the difficulty of the job.

The problem is that this on-call way of life is not conducive to actually fixing problems faster. In a perfect, company-centric world, everyone would get paged for every problem with the logic being that one of the team members actually has the information needed to solve the problem. But that’s not going to happen. And unfortunately, the truth of the situation is that you’re not sure who that one person with the correct knowledge to solve the problem will be.

The question then arises…how can team members have more knowledge about what is going on with the complex systems in their architectures while also maintaining their quality of life?

Consider Twitter and Facebook user behavior. I have a cousin that lives in Chicago. I have seen her in-person once in the last 30 years, yet I know she remodeled her living room, I know about her work and I know where she took her last vacation. I know these things because the Twitter and Facebook experiences leverage something called Continuous Partial Attention, a term coined by Linda Stone in 1998. Basically, I pull my phone out of my pocket, swipe once, and gain a disproportionate amount of information for the effort (or conscience thought) I put into it.

If you’re in DevOps, then the idea of Continuous Partial Attention is something you’re already living daily. Now imagine putting CPA to work for your team. Everyone can have an eye on the infrastructure, but not “feel like it”. The on-call team member is still responsible but if everyone has an idea of what is happening, the likelihood of someone knowing the answer is revealed sooner. Now everyone wins because the problem is solved faster, getting the team back to their lives and the company back to revenue generation.

March 13, 2014
Step One Of DevOps Ignores Technology

I’ve spent a bunch of time talking with Adrian Cockcroft, former cloud tzar at Neflix, and listening to his various talks and presentations. I’ve also spent a bunch of time looking around the various rooms within which he presents and seen the dazed look of attendees who have rightly assumed that just seen a picture of the way organizations should be. Netflix is unquestionably an exemplar for IT reinvented – where innovation, agility and developer enablement are natural parts of what they do.

But then I’ve seen these new disciples of the “Netflix way” write a list of the technologies that Cockcroft detailed and attempt to shoehorn those same approaches into their own organization. All to often the result is disappointment, failed projects and a swing back to the traditional rigid ways of doing things.

These thoughts struck me then I hear about this new masthead and its aim of creating a hub for DevLops thought leaders – surely giving IT practitioners a good place to find the latest tools and techniques will help spread the DevOps gospel?

Well yes, and no. You see I’m a firm believer in the viewpoint that DevOps has very little to do with products, processes and policies, and instead is a direct result of a particular type of culture. On the one hand you have Netflix, clearly a cultural outlier with its openness, willingness to experiment, embracing of failure-driven iteration and aim of planning for failure. On the other hand you have traditional IT shops that are top-down, driven by a rigid policy framework and consider the “operations department” and the “developer team” as two distinct entities.

This was a topic that Christian Reilly (he of the sartorial elegance and funny accent tendencies) and I discussed a couple of years ago, before the DevOps hype had really started to hit. In the video, he reflected directly on his organization, Bechtel, as an outlier at one end of the spectrum, while Netflix is an outlier at the other. It’s a somewhat dated video, and talks about public/private cloud, but the themes in terms of organizational readiness hold true for DevOps as well.

[youtube http://www.youtube.com/watch?v=gVG1Pj4cW-g&hd=1]

So my aim in my regularly irregular DevOps column in here is to talk about everything but the technology. And where better to start that the first step towards DevOps which is, I believe, all about building cultural bridges rather than making technology choices. It should be a natural concluding that, since DevOps is all about bridging the developer/operations span, that perhaps getting people in a room to talk about their particular drivers and metrics would be a good idea. But alas most people go from talking about DevOps to deploying their choice of automation tool.

There’s so many things to think about in embarking on this process – over on the ScriptRock blog Alan points out that visibility is a key first step before automation is embarked upon. While I agree with him that visibility is key, for me the money quote comes in his post where he writes:

Don’t automate what you don’t understand

But to then suggest that the first step should instead be a visibility tool does little to improve the outcomes – unless both sides fo the organizational divide are in the same room and accepting a common lingua franca and viewpoint on the data – visibility achieves little. So takeaway #1 focus on the culture. There’s lots of ways to build the bridges needed to change the way an organization looks – I’m going to cover some of that stuff over time.

March 12, 2014
Visualizations of Continuous Delivery

From the Continous Delivery Blog:

Nhan Ngo, a QA engineer at Spotify, made four fabulous visualizations while reading Continuous Delivery. She has very kindly agreed to make them available under a Creative Commons license so feel free to share them, download them, and print them out (click to get a higher resolution version). Thank you Nhan!

February 20, 2014
Over 63% of Active Cloud Developers Release Updates at Least Once a Week, 25% Release Daily Updates

Cloud Enables Continuous Delivery and DevOps, According to New Evans Data Survey of Cloud Developers

SANTA CRUZ, CA. January 21, 2014 Cloud is accelerating the implementation of a rapid continuous delivery model, with 25.9% of developers active in Cloud development releasing updates or new versions at least once a day, and 63.3% releasing at least once a week, as Evans Data’s new Cloud Development Survey shows. The survey, conducted in November – December 2013 with 436 active Cloud developers also showed that 51% feel that Cloud computing in general will improve coordination between development and operations, which will also help to enable continuous delivery.

However, opinions and practices diverge across segments. ISVs are most likely to release software quickly, with 45.7% releasing updates daily and 73.6% making updates at least weekly; whereas only 12.9% of internal corporate enterprise developers make daily releases and 66.4% make them at least once per week.

The two groups also have different opinions about Cloud and DevOps: 76.6% of ISVs think Cloud will make coordination between Development and Operations better and only 9.9% think it will make it worse, but developers working in an internal corporate enterprise are evenly split with 35% thinking Cloud will make coordination better and 35.9% thinking it will make it worse. Additionally another 22.3% of internal developers think Cloud will erode the need for Operations altogether.

“There are obvious differences between developer segments,” said Janel Garvin, Evans Data CEO. “ISVs were Agile early adopters and today commercial apps have to be updated frequently in order to stay competitive, whereas internal corporate development is where a continuous delivery and DevOps model would be the most beneficial, and yet that’s where there is the most resistance.”

Evans Data’s Cloud Development Survey has been conducted every six months for the last 5 years. The current survey report contains over 200 pages of data on such topics as Cloud Configurations, Cloud Integrations, Cloud as a Development and Test Platform, Development Tools in the Cloud, Cloud and Mobility, Cloud Storage, Runtimes and Frameworks, Security and Compliance, and more.

See complete Table of Contents here: Table of Contents

About Evans Data Corporation

Evans Data Corporation provides regularly updated IT industry market intelligence based on in-depth surveys of the global developer population. Evans’ syndicated research includes surveys focused on developers in a wide variety of subjects.

Copyright 2014 Evans Data Corporation. All other company names, products and services mentioned in this document are the trademarks and property of their respective owners.

February 16, 2014