Tag: continuous delivery

  • DevOps is a Lifeline to Connected Mainframe ROI

    DevOps is a Lifeline to Connected Mainframe ROI

    A new IDC white paper sponsored by IBM and CA Technologies reveals the adoption of DevOps is a hallmark of those organizations that are actively modernizing and integrating legacy systems such as a mainframe to support digital transformation.

    Early adopters are blazing a path for faster innovation and greater ROI.

    DevOps Delivers Mainframe Modernization and Integration

    I’m encouraged to see DevOps recognized as an important element in realizing a “connected mainframe” vision. Respondents demonstrated a continued commitment to modernizing their mainframe environment.

    The IDC study confirmed that leveraging Java on the mainframe was one of the most popular approaches. In fact, I’m constantly surprised at how few managers realize that these days, Java and Git can be used by developers in such a way that allows them to completely separate themselves from the mainframe “green screen” environment when coding or maintaining applications.

    DevOps automation has also helped organizations overcome many of the cultural and operational challenges to a fully end-to-end enterprise by aligning application development tools and orchestration chains across multiple platforms and teams.

    Adopt a Business-First Approach

    Customers I’ve spoken with are experimenting with DevOps for mainframe tools and practices, with many piloting new approaches across the life cycle. They’re immediately becoming more agile, realizing shortened development cycles, improved collaboration between distributed and mainframe teams and faster MTTR that maximizes availability. In all, these early adopters have benefited from increased speed to market, improved business agility and better platform economics.

    The IDC study concurs, identifying more effective delivery of applications and services as a powerful cost-saver, with savings of $58,900 per application achieved through increased developer productivity and day-to-day support efficiencies. By helping mainframe organizations to realize improvements at every stage of the application life cycle—from build through test, deploy and operate—DevOps delivers compelling benefits; for example, from our recent study Accelerating Velocity and Customer Value with Agile and DevOps:

    • Advanced DevOps users reduce the time taken to develop, test and release new applications by 42 percent.
    • Advanced agile users reduce their time to decide and act on new opportunities by 40 percent.
    • Advanced agile users accelerate the time to develop, test and release new apps by 36 percent.1

    Excited? I encourage you to catch up on the full IDC White Paper here.

    — Aline Gerew

  • DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    Blue Ocean brings easy-to-use continuous delivery for teams to everyone. Years in the making, Blue Ocean is a major project built from the ground up for Jenkins Pipeline. I had a chance to speak with two of the key contributors from CloudBees and the Jenkins community, James Dumay and R. Tyler Croy. Tyler is on the Governance Board for Jenkins.

    Blue Ocean provides:

    • Sophisticated visualizations of CD pipelines, allowing for fast and intuitive comprehension of pipeline’s status.
    • Pipeline editor makes creation of pipelines approachable by guiding the user through an intuitive and visual process to create a pipeline.
    • Personalization to suit the role-based needs of each member of the team.
    • Pinpoint precision when intervention is needed and/or issues arise. Blue Ocean shows where in the pipeline attention is needed, facilitating exception handling and increasing productivity.
    • Native integration for branch and pull requests enables maximum developer productivity when collaborating on code with others in GitHub and Bitbucket.

    As usual our conversation in the streaming media player is immediately below.

     Streaming Audio

    Transcript of our conversation

    Alan Shimel: Hey everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Welcome to another DevOps Chat. We have two guests today on DevOps Chat. We have James Dumay and R. Tyler Croy of the Jenkins community. James, Tyler, welcome to DevOps Chat.

    James Dumay: Nice to be here, Alan.

    R. Tyler Croy: Thanks for having us.

    Shimel: Thank you. Let’s start off though with just a little background of each of you. James, you’re coming to us all the way from Australia. In deference to the distance, we’re going to let you go first. Why don’t you share with our audience a little bit of your background?

    Dumay: Yeah, sure thing. So I’ve been probably building development tools for the last 10 years. I think I’ve found my calling here. I love making developers more productive. I also want to make developers happier. So I do have this bee in my bonnet that developer tools are difficult when they’re boring and they’re not very pleasing. It’s my life’s mission to turn that around.

    Shimel: Excellent. Tyler, how about you?

    Croy: I’ve been with the Jenkins project a little over eight years now. I started using it when I was a back-end services engineer, a few startups ago. Every single company that I’ve joined needs more continuous delivery or some non-zero amount of continuous delivery stuff. So I found myself getting more and more ingrained in the Jenkins project and bringing Jenkins to bear in companies to ship products faster. Now I work at CloudBees talking about how you can do that and help other people see the light with some of the Jenkins stuff I’ve been doing for a while.

    Shimel: Tyler, I don’t want to embarrass you. You actually are—I don’t even know the word, but you’re one of the—on the steering committee or the governing committee for Jenkins. Is that the right way to put it?

    Croy: I guess you would say I’m on the Jenkins governance board. In the beginning of the Jenkins project, there was Kohsuke Kawaguchi who was the founder of the project, and then there are a few other core folks that were floating around that helped get Jenkins off the ground. Andrew Bayer who is a major contributor to the pipeline toolset, is one of those people. So I’ve just—Jenkins became a really important part of my life. I started spending a hell of a lot more time with Jenkins, and now I’m one of the people that makes sure that the project continues to move forward.

    Shimel: Excellent. James, I don’t know if you mentioned your role other—at this point, other than you’re cuckoo for Jenkins. What exactly is your role right now?

    Dumay: I’m director of Product Management at CloudBees, but I’m also a community leader for the Blue Ocean project. I do all the outreach and talk to all the users. It’s good fun, but previously before I was at CloudBees, I was at a small Australian startup called Canva. They do an online design tool. Prior to that, I spent seven years at Atlassian, where I was product manager for actually a competing product.

    Shimel: Absolutely. Well, we’re allowed to have competing products. They may not be any good. I’m only kidding. James, you mentioned the magic word. You get the first prize today. That was Blue Ocean. Today’s a bit of a—more than a bit—today is a big day in the Jenkins community. This release has been highly anticipated. It’s been in beta and in testing, alpha before that for some time. Talk to us. What about it? Why should people care?

    Dumay: All right. That’s a big question. So I guess we’re living in a really interesting time in the industry. We have this—there’s this ride of exponential change that is happening across our industry, whether it’s tooling and technology and process, or just the raw number of people writing computer software in the—we’ll be in the year 2020 soon. I think if you look back in the previous 10–20 years, the amount of companies out there that are writing software today and were not writing software 10 or 20 years ago. So Marc Andreessen speaks about software eating the world, where all the value that companies provide slowly but surely are being made, not by the engine in a Ford motor vehicle, but it’s the software on board the Ford motor vehicle.

    So it’s an interesting time to be a software developer, or to be in this field, but it’s also a really interesting time to be a tools creator. I think with this increase of people in the industry—it’s not like we have lowered the bar to what we call a software developer, but I think there’s a lot more people today who, in their jobs, whether it be financial services, or in other industries, who are finding their job involves writing software. I think there’s a big challenge here, and Blue Ocean is founded on going out there and solving this problem, that how do we make the millions of software developers or even people who are just writing software as part of their jobs, how do we make them more productive? How do we make sure they can get what they need to get done as quick as they can get it done at the highest quality that they can get it done with the best tools possible?

    So with Blue Ocean, we’re sort of focused in on the practice of DevOps and on continuous delivery. We set ourselves a goal. What if we can make it really easy for people to adopt continuous delivery? Blue Ocean is our answer to that.

    Shimel: Tyler, James—I think James made some important points. What can you add there? Why—let’s step back a second. Let’s say our audience is vaguely familiar with Jenkins. Most of them probably use it, but there’s some maybe that don’t. What is—let’s start with what is Jenkins to them? What does Blue Ocean represent to Jenkins?

    Croy: Sort of at a high level, Jenkins is an automation server. Jenkins is probably the most well-known tool of its kind across the entire software industry. As far as helping developers build and test and deploy their software, chances are with most organization today, if someone doesn’t think they’re running Jenkins, they might just not be aware, or they might be so far removed, or that it’s hiding, that they don’t know that it’s actually there. It’s pretty omnipresent in the industry right now.

    One of the big things about I would say the shift in the industry that has made Blue Ocean important—when I first started in northern California about 10 or— [inaudible] 10 years ago, continuous integration was this really big, important thing. I kept coming to companies who either didn’t have a continuous integration server, or didn’t practice—nobody but the developers knew that there was a continuous integration server. As the industry has shifted towards this more and more rapid pace of “Let’s practice continuous delivery. Let’s get product and value to our customers as soon as possible,” it’s no longer acceptable for just the developers to get feedback to what’s going on in that process.

    So I think the important thing for Blue Ocean, and I would say broader software industry, is that continuous delivery is not a developer thing. It’s an entire team thing. It’s an organizational thing. Blue Ocean is designed from the ground up to make sure that people who might not be writing code every single day, or they might be designers, or they might be product managers, or stakeholders of some form or fashion in the software development process. They need to know what’s going on and Blue Ocean is going to give them a window into what’s going on in the delivery pipeline. That’s a pretty dramatic shift from the Jenkins that was created 10 years ago, which was just for developers.

    Shimel: Got it. Got it. Now guys, I’ve had the—I don’t know if the word is a pleasure, but I’ve had the—well, it was a pleasure in a lot of ways, but I’ve had the experience of being involved with open-source projects in the past. It’s a fickle thing being part of a community. It’s even harder when you have a corporate entity such as CloudBees in this—CloudBees isn’t alone in this. There are many companies that are mentoring, managing—whatever you want to call it—open-source projects. Talk—I loved what I saw of how that relationship was handled as it applied to Blue Ocean.

    Guys, can you give us a little color on that? No pun intended with Blue Ocean and color, but a little background on how you worked with the community to deliver, I think, what the community consensus was what was needed.

    Dumay: Just to preface this. So this is my first time working full-time on behalf of the commercial entity for _____ community. So I—when we started at Blue Ocean, I kind of put myself in Tyler’s very capable hands. Tyler had had a lot of previous experience, not with Jenkins, but with other projects, walking that fine line between community and the need for the business sponsor, I guess. So it’s been an interesting process. I think certainly for CloudBees, a healthy Jenkins community is a healthy CloudBees, and a healthy CloudBees is a healthy Jenkins community. It all feeds into each other. As long as, I think, we take things from a project perspective, like what’s good for Jenkins, we’re making good decisions in both aspects.

    Certainly, we had been running—more in terms of Blue Ocean itself, we had been running for multiple years Jenkins community surveys, and one of the top issues people would have liked to see addressed in that feedback had been the user experience with Jenkins. They really wanted it to be easier to get started. They really wanted clarity when they’re looking for particular cases, information. I think there was a real groundswell there to see some improvements, and see some sort of more modern thinking around how to solve problems. I hope that we’ve done that. Certainly the feedback that we’ve been getting from the community has been pretty great.

    Just on the community itself, I think software developers can be a pretty passionate tribe of people. So it’s—the Jenkins project is no different from the wider developer community. They’ve been passionate in a very encouraging way, in a very forgiving way as well. Particularly when you go ahead and think about any product that has—web product that has been redesigned. So the people get very upset. They’re very invested in the tools that they use, or the products that they use, and then you move their cheese, and people go “Where did that thing go? Where did this other thing go? No. I was using that. Bring it back.” I think with the Jenkins community, I think they’ve been very—I think they’ve wanted the change for so long that as things change, we—they’re getting some new goodies in their bag and they’re happy to let some of the old bits disappear.

    Croy: I think there’s also—if you look at that feedback from the Jenkins user list going back years and years and years, there’s been—most people, I would say, that contribute to the Jenkins project, note they’re new, I guess past tense, because Blue Ocean is one meadow now—knew that something needed to get fixed, and someone needed to do something to really improve and set up Jenkins for the next 10 years. The skill set and the passion and the vision really wasn’t there.

    So when James and his team, his colleague Michael Neale and some of the other people, really started to get involved, I think it was easier for other contributors in the project to rally around that. It was clear that not only did they know what they were doing, but they understood the challenge in that we needed to think about the design from the ground up, as opposed to reskinning or reseaming Jenkins. They needed to evaluate it from a user experience standpoint and start from 2016 rather than 2006, which is when the project really started. So I think that was really helpful to have some—a passionate group of people with vision to drive it forward.

    Shimel: A passionate group of people with vision can accomplish a lot. That’s for sure. Guys, let me ask you—we’re almost out of time. What—for each of you, and we’ll go with James first. James, what do you think is the single biggest aspect or feature of Blue Ocean that our listeners should take a look at?

    Dumay: That’s very unfair, Alan. I love them all.

    Shimel: How can a parent decide? But guys, so pick one. Doesn’t have to be your favorite or biggest, but one that we’d like to call out.

    Dumay: The official pipeline editor. So _____ delivery pipeline is difficult at the best of times for people to create. So we set ourselves a challenge. What if we could make it very easy for people to create a continuous delivery pipeline using Blue Ocean UI. The one thing I really like about it is it really is for everyone. We talk a lot about—we’ve got a lot of plans for the Blue Ocean in the future. One thing we talk about is the Fisher Price’ing of the editor. I don’t know if you’re familiar with Duplo blocks you give a toddler. But you can get all these different attachments, all these crazy things, and you can customize your own creation using Duplo. It’s non-checkable Lego. So really, Duplo is for everybody. So anybody of any age can—of any skillset, can construct something from Duplo.

    The thing that I like about the—I guess the vision behind the editor is anybody can construct a continuous delivery pipeline, even if they don’t have coding knowledge. Maybe they want to take—they have—we can go as far as they can have a PHP website on a Dropbox folder and they want to upload that, deploy that continuously to their webhost, their DreamHost or something like that. That’s the kind of—we want to bring continuous delivery to everyone.

    I think the communal pipeline editor is the vehicle to do that. One of the great things about the editor as well is that it is what you see is what you get. So when you build it in the editor, that’s exactly how you visualize it later on in Blue Ocean, as that pipeline is executing. It’s really powerful in that way.

    Shimel: Great. Makes sense. Tyler, how about you?

    Croy: So my interactions with Jenkins are typically when something goes wrong. I think that’s maybe a bit more common for an infrastructure administer or developer. So, for me, I would say the No. 1 killer feature with Jenkins—with Blue Ocean and Jenkins is that the clicks to get from a failure or something going wrong to seeing what actually went wrong, it’s pretty much one click. So the visualization of status is so much faster and more immediate in Blue Ocean that when I come to Blue Ocean to figure out what test failed, or what went wrong in my pipeline, I get that in a matter of seconds, as opposed to drilling around and hunting through console help. So for me, that’s probably the killer feature.

    Shimel: Make sense. Guys, we’re going to wrap up here in a moment, but just quickly, for people who want to find out more about Blue Ocean, where can they go? James, Tyler?

    Dumay: No problem. They can go over to Jenkins.io/projects/blueocean or the Jenkins blog, which is Jenkins.io/blog.

    Shimel: Okay, Tyler, I’m going to hit you with the last question. Now that Blue Ocean is 1.0, what’s next?

    Croy: [laughter]

    Shimel: [laughter] You didn’t expect to get a rest, did you?

    Croy: No, no. I think the really important thing that’s next for the Jenkins project is I would say the next three months of Jenkins pipeline and Blue Ocean adoption. Now that we’ve got the tools that we’ve brought to the broader software industry for building and constructing and running continuous delivery pipelines, we’re going to need to iterate, on them and we’re going to need to make them better as more and more people start to adopt continuous delivery. I think we’re, certainly before the end of the year, we’re certainly going to find new things that we can add into Jenkins to make that an even more enjoyable experience.

    Shimel: Absolutely. Hey guys, congratulations. I know it’s easy on release day to say something came out. There was a lot of work here, an awful lot.

    Croy: Indeed.

    Dumay: Very much so. Thanks.

    Shimel: Thank you, James, Tyler, great job. R. Tyler Croy, James Dumay of CloudBees and Jenkins talking about Blue Ocean, the big news around Jenkins and CICD Pipelines. Guys, thanks very much. Hopefully we’ll have you back soon on another DevOps chat.

    Croy: Thanks a lot. See you later.

    Dumay: Thanks.

    Shimel: This is Alan Shimel with DevOps Chat. We’ll see everyone soon on another DevOps chat, but until then, have a great day.

    — Alan Shimel

  • CD 101 Podcast: The What, How and Future of Continuous Delivery

    CD 101 Podcast: The What, How and Future of Continuous Delivery

    Now that we’ve arrived at Episode 4 of our CD 101 Podcast, let’s address some basic concepts—like the what and how of it all and the future.

    Wait … perhaps we could—or should—have touched on these key topics earlier. Or not. At least not the future part? Anyway …

    While this (mostly) backwards-looking orientation may seem a bit odd, I’d argue that we’re actually navigating the conversation on precisely the correct path. Let’s rewind for a moment to look at where we’ve come from.

    Episode 1: We highlighted many of the fundamentals of this thing called CD, yet we did so from more of a conceptual and best-practices standpoint. While the ideas and processes involved do resonate in the real world, the topics we cover in this episode are bit closer to the water-cooler conversations we’re hearing about CD as it grows in practical adoption.

    In Episode 2: We covered the whole how do you “realize agility” piece of the conversation. This is important and a precursor to some of these other basic questions. The entire process of digital transformation begins with getting agile and you can’t truly adopt continuous delivery without doing so; therefore, this was another good place to feed today’s discussion.

    In Episode 3: We looked at the prospect of re-inventing the “Modern Software Factory” with agile development and continuous delivery. OK, so, perhaps we were getting a bit ahead of the basics here, but I’d maintain that this is an important piece to consider upfront that builds on these other building blocks. As with the topics covered in Episode 2, it is critical to understand the big picture challenges and benefits before you begin to get your hands dirty.

    And now for some nitty gritty.

    In Episode 4, we hear from Shamim Ahmed, CTO of Continuous Delivery Solutions at CA Technologies, as he answers the nine burning questions he most often hears in speaking to enterprise practitioners as they look to employ DevOps and Continuous Delivery practices in the real world.

    So, while these previous conversations were material, this is a crucial set of topics to consider as you invoke your own strategy, including:

    1. What is the difference between DevOps and continuous delivery?
    2. What are the key impediments/obstacles to achieving speed/quality in CD?
    3. How do we overcome these obstacles?
    4. How do we get started on the CD journey?
    5. What are the key top-level metrics you want to track in a CD program?
    6. What org changes do we need to make to implement CD?
    7. What the key capabilities we need to implement?
    8. How do we integrate all the different tools we have in our environment?
    9. How will the future of continuous delivery evolve?

    OK, that last part is a bit more postulation on our part—though we like to think on the practical side, based on the answers to all these other important real-world adoption dynamics.

    Tune in and hopefully learn a good deal about where your approach stacks up, and needs to evolve.

    As always, you can find said Episode 4 of the Continuous Delivery 101 Podcast by:

    • Listening to it on your computer on YouTube
    • Downloading it from iTunes store
    • Downloading it via the Podcast App by searching for “Continuous Delivery 101 podcast”

    Enjoy!

    — Scott Edwards

  • Self-Healing Service Management and the Future of DevOps

    Self-Healing Service Management and the Future of DevOps

    How can DevOps teams take continuous delivery to the next step? Part of the answer lies in self healing, which could optimize performance management and monitoring and underpin the software delivery pipelines of the future.

    Self healing means the ability of systems or environments to detect and resolve problems automatically. It eliminates the need for manual human intervention, upon which most systems today still rely to fix issues.

    Self healing is better than depending on humans for several reasons:

    • Automated solutions are less likely to miss issues by mistake, or to make errors when resolving them.
    • Self-healing technology is better positioned to fix problems faster than humans because it can react instantly based on rules or machine learning. It doesn’t have to stop and think about the issue before taking action.
    • A self-healing environment can scale without limit. This is a key advantage over manually managed environments, whose scalability is limited in some respects by the availability of human admins.

    Self Healing and Continuous Delivery

    DevOps teams already take advantage of many other kinds of automated tools to help achieve continuous delivery.

    They use continuous integration servers to automate tests. They adopt release automation tools to streamline deployment. They implement orchestrators and scripted infrastructure to provision environments automatically.

    Yet, when it comes to performance management and monitoring, the typical organization is a far way off from achieving a fully automated process. Even the best application performance management (APM) tools of today are primarily capable only of detecting problems and displaying information about them. They depend on humans to interpret and react to that information.

    That dependency is a major obstacle for achieving fully continuous delivery. You can’t release code quickly if your process for finding and solving problems related to the code is mostly manual.

    By making better use of self-healing technology, DevOps teams can speed continuous delivery in the following ways:

    • Developers and admins can spend less time on monitoring and more time completing other tasks that can’t be automated.
    • Ideally, teams will be freer to switch between development environments and frameworks without having to establish a new monitoring workflow. Self-healing tools will adapt to whichever environment they have to work with.
    • Because problems can be found and fixed faster, infrastructure utilization can increase. The need for a buffer between average usage and overload can become smaller because automated healing solutions will be able to fix problems before they lead to failure.
    • Teams can establish better continuous feedback loops because, by removing the human element from performance and monitoring, incidents can be reported instantly, consistently and in a way that makes the data easily accessible to everyone on the team.

    To be clear, the technology for self healing does not yet fully exist. Developers over the past several years have made great strides in automating configuration, service discovery and environment provisioning, But perhaps it’s time to make them a more prominent focus. They’ll enable the DevOps innovations of the future.

    — Chris Tozzi

  • Where Does the Database Fit into Continuous Delivery?

    Where Does the Database Fit into Continuous Delivery?

    Continuous delivery (CD) is increasingly becoming the norm in software development, with companies releasing updates more and more frequently. Those that aren’t are exploring how they can catch up. But in all of this push to DevOps and CD, it’s vital not to forget the database. Changes to applications or web services often require changes to the database, which means companies need an end-to-end process that spans both application and database development if they want to successfully embrace CD.

    However, many companies still work in silos, with applications and databases developed separately. So while the ability to deploy application changes across environments is relatively common, supporting databases in a truly elastic environment remains a major challenge for organizations.

    To find out the current state of database DevOps, and how it can be included in CD, Redgate surveyed 1,000 SQL Server professionals across the world. While we found companies were keen on implementing DevOps, with 80 percent saying they will have adopted it within the next two years, only 20 percent are currently applying DevOps practices such as version control, continuous integration or automated deployment to their databases.

    The Need for Change

    This isn’t because companies don’t recognize the need for database DevOps—37 percent said they are deploying database changes either more than once a week or daily, demonstrating a requirement for automation. Indeed, the main driver for adopting DevOps in this area is to increase the speed of database changes (cited by 26 percent of respondents), followed by freeing up developers for more added value work (17 percent).

    Companies also recognize the drawbacks of continuing traditional, siloed database development practices—26 percent said it increased the risk of failed deployments or downtime when introducing changes. This was followed by slow development and deployment cycles and an inability to respond quickly to changing business requirements (both 18 percent). Sixteen percent also cited poor visibility of the change management process as another issue. This shows the vital importance of fast, successful database changes and deployments to business today.

    For companies with 5,001-10,000 employees, slow development and release cycles were seen to be more of a drawback than application downtime, while for organizations with more than 10,000 employees, the inability to respond quickly to changing business requirements was deemed to be a slightly more significant downside.

    Moving to DevOps for the Database

    As well as understanding the business need, the survey showed that organizations are now better structured to enable continuous delivery for database changes. The old picture of companies made up of silos of developers and database administrators that don’t work together, for example, is far from the truth. Seventy-five percent of companies had teams that included developers who were working across databases and applications, with just 25 percent having dedicated database developers. In 60 percent of companies, developers were responsible for building database deployment scripts. Fifty-eight percent of companies said the integration between the two was either good (38 percent) or great (20 percent), meaning teams work together on a planned or ad hoc basis. Just 12 percent classed integration as poor, with DBAs working in silos.

    However, the research highlights two challenges to overcome:

    Different processes and tools—Despite the levels of integration within organizations, there is still a gap between how companies operate and automate when it comes to applications and databases. For example, while 81 percent of respondents use version control for their applications, just 58 percent apply it to database development. Thirty-nine percent use continuous integration for applications, yet only 20 percent apply the same practice to their database. Clearly, there is still more that can be done to bring the two together through common practices and the use of third party tools.

    The skills gap—The greatest obstacle to moving to an overall DevOps way of working was a perceived lack of appropriate skills (cited by 21 percent of respondents), ahead of a lack of alignment between the development and operations teams (20 percent). Only 9 percent said that their executive leadership didn’t support the shift.

    When it came to integrating database changes into the DevOps process, consistency was top of the list of obstacles, with 32 percent believing that synchronizing application and database changes would be the biggest challenge, followed by overcoming different approaches to application and database development (25 percent). Perhaps unsurprisingly, 19 percent also mentioned preserving and protecting business critical data as the largest obstacle to overcome.

    It’s Happening Sooner Than You Think

    The good news is that many companies are confident they can quickly overcome the process and skills challenges. When asked how long they estimated it would take their organization to move from traditional database development practices to a fully automated process for deploying database changes, more than half (51 percent) said it could be done within a year, with 20 percent believing it could be achieved in six months.

    Digging down into the data, those that have already adopted DevOps in other processes are much more confident the switch can be achieved quickly. Sixty-eight percent of this group cite 0 to 12 months as the time it would take to move to a fully automated database development process, compared to 28 percent of those who had no plans to adopt DevOps practices. In fact, 43 percent of this latter group cited more than two years as their estimate.

    Our research shows that organizations recognize the potential of applying DevOps to the database to gain all of the advantages CD brings. They see that it speeds up software development, frees developers to do more value-added work and increases the rate at which database changes are delivered.

    At a time when organizations need to operate in a faster, more seamless manner to thrive in ever more competitive markets, introducing DevOps and CD to the database can transform their development process. To read more about the research and the “State of Database DevOps,” download the full management report.

    About the Author  / Matt Hilbert

    Matt Hilbert is a technology writer at Redgate Software with 20 years’ experience working for lots of the world’s biggest tech companies – and many of the smallest. He has a particular fascination for emerging technologies and is on a continuing mission to decompile, untangle, and explain techspeak to a wider audience, and excite people about the endless possibilities technology offers.

  • In the Application Economy, Every Company is a Software Company

    In the Application Economy, Every Company is a Software Company

    Recently, I was in New York to attend the Third Annual DevOps Virtual Summit. (Yes, I had to be at a “virtual” summit in person—while it’s virtual for the attendees, it occurs in real life for the speakers, panelists and support staff.)

    The broadcast took place in a small recording studio that featured a lobby adorned with autographed photos from celebrities who had used the facilities previously. Sylvester Stallone, Al Pacino and even John Stamos—complete with a full mane from the “Full House” days—were all looking down on us from the walls.

    Anyway, as the speakers were introducing themselves in this lobby prior to the event it occurred to me that the sampling of speakers was illustrative of the importance of DevOps across industries. The companies participating in the event were not what you’d traditionally consider a “software business,” but yet they’d made an investment in their software development practice—recognizing the importance of competing in the application economy. It underscored the point that in the application economy every company is a software company, regardless of what industry they are in. Which is why the concept of DevOps and Continuous Delivery should be top of mind, even if your company may not see itself as being “in” the software business. Regardless of what end product your company sells, you rely on your software and applications to do so.

    Take a look at the panelists and the companies they represent to illustrate this: Silvia Prickel from United Airlines. Matt McComas from GM Financial. John Hashimoto from CNN. And Kelly McCartney from Jeweler’s Mutual Insurance Company.

    An airline, an automobile financing company, a news organization and an insurance company that’s been around for 100 years (literally). These are not companies that were born digital, like many of the web-based entrants you might typically associate with DevOps. Instead, these are traditional organizations that recognized the need to make a digital transformation.

    And the results were pretty impressive. We often focus on speed when we talk about continuous delivery, but it’s important to remember you also can see improvements in quality. The below image was taken from the United presentation and shows the dramatic decline in production outages.

    This is not to say that improvements in speed were not seen as well. Matt McComas from GM Financial spoke about how his company is now averaging 1,800 deployments per month, with each one taking just 3 to 5 minutes.

    I won’t give away any more important details here. If you’re interested to find out more, I encourage you to watch the replay of the webcast: http://bit.ly/DOVSreplay

    — Brendan Hayes

  • Beware False DevOps Metrics

    Beware False DevOps Metrics

    Metrics are important for any manager seeking to continuously improve critical work processes and the resulting work-product.

    That’s why DevOps leaders need DevOps metrics. With the right ones, those leaders can guide their organization’s adoption of DevOps best practices—progressively optimizing staff productivity, business agility and customer experience.

    But, what are the right metrics for DevOps success? And, what are the wrong ones?

    These next few blogs will offer field-proven guidance on DevOps metrics. Much of the material in these upcoming blogs can be found in the book, “DevOps for Digital Leaders,” which I co-wrote with Kieran Taylor and Peter Waterhouse. And I’d love for you to comment below so we can all share lessons learned about how to effectively measure DevOps maturity—and, just as important, how not to measure it.

    Change Your Metrics, Change Your Culture

    DevOps leaders tend to struggle with metrics because DevOps entails changes that are both operational and cultural—and span different teams or functional areas, including development, test and operations. So inexperience may cause leaders to adopt new ones that are counterproductive—or, as is often the case, continue using traditional ones that don’t align well with the cross-functional nature of DevOps objectives.

    Three pitfalls have proven to be especially common in the transition to DevOps:

    • Vanity metrics. These appeal to the “hero” mentality of individual coders, rather than the collaborative process goals of cross-disciplinary DevOps and continuous delivery teams. They include total lines of code produced and total function points created. If incentives are linked to these metrics, developers can focus too much on volume at the expense of other essential activities such as refactoring and design simplification.
    • Those that promote interteam conflicts. Metrics that pit teams against each other undermine critical DevOps behaviors—such as code-sharing, mentoring and constructive peer reviews. So, while gamification may be useful in other areas of the business, Agile leaderboards that rank teams based on the prevention of extraneous deployments and changes can actually work against DevOps culture.
    • Traditional metrics. Many DevOps leaders persist in utilizing traditional/incumbent ones such as mean time between failures (MTBF) and the ratio of full-time equivalents (FTEs) to servers. But while these may have been useful in the past, they can work at cross-purposes with DevOps transformation. After all, with faster delivery of services, some failure is to be expected. And as IT improves its responsiveness to the business, it must look past costs alone to total economic impact.

    What Makes a DevOps Metric Useful?

    While future blogs will propose some specific metrics that DevOps leaders should find useful in their efforts to bring about cultural transformation, here are a few general guidelines to consider:

    They must be obtainable.

    A metric won’t do you any good if you can’t actually capture it. So you need DevOps tools that help you capture the metrics you need. You may also have to measure some attributes indirectly. For example, rather than measuring employee morale directly, it may make sense to use staff retention rates—which you can readily capture—as your performance indicator.

    They must be reviewable.

    Any metric you choose to employ as part of your DevOps leadership effort must be able to stand up to rigorous scrutiny in a business context. Your credibility as a leader depends on your ability to communicate its relevance to the stated values and mission of the team.

    They must be incorruptible.

    It’s never a good idea to promote metrics that can be influenced by individual team members or any group as a whole. You should also be on guard against metrics remaining entrenched—despite the fact that they may inhibit change—because bonuses are linked to SLAs associated with them.

    Metrics must be actionable.

    Useful metrics must enable DevOps leaders to make better decisions about workflows, incentives, policies, training, tools or some other “lever” of transformation. Not every such decision will be a game-changing one—but incremental gains in knowledge lead to incremental improvements in process, which collectively do change the game.

    In my next blog, I’ll discuss the metrics that DevOps leaders are using today to successfully drive the digital transformation of their businesses. In the meantime, if this is a topic that interests you, be sure to request a free copy of my book, “DevOps for Digital Leaders.”

    — Aruna Ravichandran

  • CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery

    CD 101 Podcast: How to Build the Modern Software Factory with Agile Development and Continuous Delivery

    And now, for Episode 3 … you decide if it beats “Star Wars – Revenge of the Sith.”

    I think we accidentally just set the bar pretty low, but …

    … here we go. Let’s begin with a prerequisite pithy quote from an objective industry observer:

    “If agile software development was the opening act to a great performance, continuous delivery is the headliner,” according to Kurt Bittner of Forrester Research.

    Kurt explains this concept further by saying, “The pace at which consumers expect change is causing a crisis in application development and delivery … agile was a good start, but it wasn’t sufficient to drive better business results; continuous delivery forges the broken link in the value chain, connecting business strategy with business results.”

    So there, you have it.  At least according to Forrester, continuous delivery (CD) is one of the most important evolutions of agile methodology within the modern software factory. But, there’s more.

    Andrew Binstock from Dr. Dobbs fairly well echoes this sentiment, saying: “It’s becoming clear that agile alone is no longer sufficient to keep up with the demands of the present day … software complexity and the need for constant updates are making it difficult for leading edge organizations to keep up without moving beyond agile and embracing continuous delivery.”

    Episode 3 of our podcast series discusses the importance of Agile Transformation along WITH Continuous Delivery to automated some of the development, test, and release efforts to remove some of the bottlenecks downstream in the software development life cycle in the build, test and release phases.

    Lean Agile + CD can create these 1+1=3 types of results.

    Episode 3 of the Continuous Delivery 101 Podcast can be found by:

    • Listening to it on your computer on YouTube
    • Downloading it from iTunes store
    • Downloading the podcast from your Podcast App by searching for “Continuous Delivery 101 podcast”

    Thanks for listening!

    — Scott Edwards

  • Digital Transformation and the DevOps Chaos Theory

    Digital Transformation and the DevOps Chaos Theory

    With the threat from agile startups disrupting markets across the globe, large enterprises are increasingly focused on moving to a more agile approach to business. Most organizations already have begun the digital transformation (DX) journey, but the fact that this transformation is still in its infancy and not completely finalized for many demonstrates the fluid and evolving nature of DX. Multiple IT technologies, processes, applications, systems and protocols need to be adopted and updated on a regular basis for businesses to keep abreast of changes. This does, of course, result in significant disruption for all involved.

    With this in mind, DevOps principles are beginning to have much greater impact, with the true value of this methodology being identified through a new approach. As development velocity increases, and the scale of the enterprise also increases, businesses will develop a much greater reliance on DevOps principles to rein in the chaos associated with continuous development that’s being spurred on by the pace of digital service development and increased automation.

    The key to managing and minimizing the resulting chaos is close collaboration and communication between the IT team members responsible for service development and delivery. Without this, the need for a continuous delivery pipeline operating at speed and scale, will quickly get out of control.

    The DevOps Chaos Theory

    To understand the challenges in this new business environment, it is useful to look at this at a more granular level, through the framework of the DevOps Chaos Theory.

    The pace of innovation is measured as the Velocity (V), or the number of new software releases deployed in a production environment in a defined time period. The Scale (S) factor is measured as the overall number of IT staff involved in service delivery and management in production environments, such as DevOps, SecOps, QA, system architects, DBAs, NetOps and help desk. Interaction between these team members brings the potential for miscommunication, which will increase the overall chaos. The maximum number of interactions between these IT members is S * (S – 1)/ 2, and for high-scale organizations it approaches S2/2. Based on these considerations, a logical hypothesis would identify the system-level Chaos (C) in production environments as C = K * V * S2.  K is the normalization factor that may change based on the overall adoption of DX in a specific industry and the effectiveness of collaboration and communication between the IT team members.

    Minimizing Disruption

    Collaboration between departments within the business is important to ensure the chaos is controlled. There is no doubt that automation tools play an important role in continuous delivery and allowing organizations to operate at the speed and scale they need to. However, enterprises must identify the level of constraint placed upon the IT operations team. This is crucial to establish what changes need to be made and what service performance management technology must be introduced, to prevent operations from becoming a bottleneck to the continuous service delivery cycle inherent to DX.

    Key performance indicators (KPIs) are critical when it comes to service delivery, particularly when you consider that this combines the entire stack into a single system. This stack is comprised of physical, virtual, wired and wireless layers of compute, storage and networking infrastructure and application that run at the top of the stack to deliver services consumed by end users. Using a variety of network, infrastructure and application performance management tools will obscure the system-level view across all the layers of the service stack and their interdependencies. Monitoring system-level KPIs requires access to reliable data sources, such as network traffic. An effective instrumentation of these data sources will play a key role in proactively identifying the root cause of service issues and thus reining in chaos.

    Enterprises must be able to effectively analyze the monitored data to gain insight into all the infrastructure subsystems and applications interdependencies to establish a comprehensive view of their services, accessing both real-time and historic information. In addition, effective management at a human level also should form an important part of a company’s DX strategy, if chaos is to be mitigated and crisis averted.

    More and more companies are realizing that DX offers a wealth of opportunity, but it’s crucial to understand that harnessing these opportunities requires strategy and forethought. Monitoring and managing systems will be vital, as will DevOps principles, as more processes are automated and data plays an increasingly central role to any company.

    About the Author / Michael Segal

    Michael Segal is vice president of strategy at NetScout. His product management experience spans across 10 years at Cisco Systems, where he managed all aspects of product line life cycles for several successful product lines. Michael’s technical areas of expertise include SaaS/cloud, virtualization, mobile IP, security, IP networking, Wi-Fi/wireless, VoIP and remote access. Michael holds patents in areas of networking and wireless mobility. Connect with him on LinkedIn and Twitter.

  • Release Automation: Delivering the Big Quality Payoff

    Release Automation: Delivering the Big Quality Payoff

    Have you ever gone down the path of testing the latest release of an application only to find out that you had the wrong version?

    Maybe you accidentally grabbed the wrong build or you didn’t have the correct configuration file for the environment you were testing against—or your database wasn’t updated correctly, or the script you were using was still pointing to a prior version of the software.

    Whatever the case, we can agree that keeping track of all the various artifacts, database schema changes, configuration parameters and other components needed to accurately test and deploy an application is both time-consuming and prone to errors.

    Today, many companies are looking to DevOps, continuous delivery and agile development methodologies to shorten their application delivery cycles and reduce the number of errors and the costs associated with application deployment processes. Nearly all enterprise companies are software companies, and their mere existence depends on delivering differentiating products and services via software to their customers.

    It’s imperative to be able to react to customer demands and competitive pressures quickly, if not immediately, to stay ahead of the competition. Gone are the days of yearly release cycles.

    Today we see companies deploying new capabilities into production environments on a monthly, weekly or even daily basis. At some companies, hundreds, if not thousands, of deployments are occurring across dev, test and production environments daily. The old methodologies we once used simply can’t support this type of volume and cadence.

    Employing Release Automation

    So, how are these companies transitioning to this new way of thinking? In a word—automation; specifically, by automating early and often.

    Everything about your release process is a candidate for automation. This includes environment provisioning and configuration automation, build automation, test automation and release and deployment automation.

    A customer of ours recently implemented CA Release Automation, and within eight weeks had automated 90 percent of its deployments. Deployments that once took more than five hours and a team of people now take a matter of minutes.

    “This not only saves us a huge amount of time, but it also mitigates the risk of human error being introduced by manual processes,” said Tim Dallmann, platform engineer at Jewelers Mutual.

    Another customer, a major airline, implemented CA Release Automation and immediately reduced their production outages from an average of 237 over a three-month period, down to 15, seven, six and five over the following four months.

    And Molina Medicaid Solutions reduced their cost of human error by 90 percent, all the while responding quicker to emergency deployment requests and improving deployment quality.

    Automation is critical, but I believe these results prove that implementing a framework to manage and deploy release processes in addition to automation works even better.

    Increased Flexibility and Visibility

    Continuous delivery helps break down barriers often seen between development and operations teams. It provides, even forces, a more collaborative approach and automation is a key enabler of this.

    “One of the best things about automation is that it gives us the flexibility to skill-up end users—deployments in our test environments are no longer solely the responsibility of the operations or IT teams,” explained Dallmann.

    With an application release automation (ARA) solution, artifact, build, configuration and release processes are no longer tracked with spreadsheets or embedded in complicated scripts.

    Increased visibility into these processes ultimately enables all stakeholders to take a more active role in the release process, and access to real-time information can significantly reduce the amount of time and resources needed to resolve and recover from problems when they do occur.

    Automation leads to:

    Integrating with the Ecosystem

    An enterprise ARA solution can help you create a single control point to streamline all your application delivery processes for better predictability and reduced risk. A critical component of this is the ability to integrate and orchestrate tools and technologies required along the continuous delivery pipeline, including source control, automated testing tools, provisioning and configuration management solutions and change management and performance management solutions.

    Integration with an application lifecycle management solution can provide even further alignment, governance and traceability between development projects and what is ultimately being tested and promoted to production.

    “By integrating the two solutions, we will have a complete audit trail of deployments to help us understand how, where and by whom stories have changed,” said Phil Nickolai, director of application services at Jewelers Mutual.

    “What we really needed was a solution to streamline our whole way of working,” he said. “We had numerous people working on projects, competing for resources and causing complexity. Now we’re back in control and getting smarter every day.”

    The Time Is Now

    Let’s get rid of the problem that exists between the keyboard and information kept in spreadsheets, scripts or emails. Not only will you stop wasting time testing the wrong version of an application, but you can also ensure you have the right test data, the appropriate test cases and the correct configuration parameters for your environment.

    Stress-inducing release weekends and nights become a thing of the past. Developers can spend more time on developing innovative capabilities that generate revenue and keep customers coming back for more.

    — Tim Mueting