Category: Features

  • Five Common Aspects to Building a Continuous Collaboration Culture

    Five Common Aspects to Building a Continuous Collaboration Culture

    For some reason talk of DevOps and culture can spark heated debate. Some contend DevOps is mostly all about culture, others say it comes down to the tools that enable collaboration. Some say it’s all about building the right processes. What if, to differing degrees, they are all right? Right. It can be a silly debate, especially when some argue that one of the three is more important than the other. After interviewing developers, operations, management, industry analysts, vendors, and IT managers I’ve concluded that building continuous collaboration and improvement culture is about the proper orchestration of people, process, and technology.

    It’s about tearing down barriers between operations and development teams and getting better individually and collectively. But what does it take to achieve a culture of continuous improvement and collaboration? Over the past 18 months I’ve noticed a few common threads that repeatedly surface in these conversations about getting there, and want to share them here. This is not meant to be an exclusive list in such a complex topic as organizational change, but a way to spark some though and conversation on the subject.

    Here they are in no particular order:

    Encourage conversation

    This sounds simple, but teams that work together tend to play and talk together – and it ends there. There is very little play and talk with other teams in IT. Encourage developers and operations teams to spend time together in things that are not directly related. This can be as simple as having lunch together on a regular basis. Matt Selheimer, a regular here advised just that in our Q&A with him of DevOps and Culture Change. “One thing I recommend is to have your developers and system administrators have lunch once a week. Have your teams get to know each other better and understand each other’s work better. That’s what is important when it comes to culture change.”

    Agreed. And consider adding fun get-togethers, perhaps attend conferences together, engage in outdoor activities that help to build teams. Whatever works for your people that will help to foster communication and teamwork. While important at relationship building, having lunch and attending conferences together certainly isn’t enough.

    Go for a number of swift wins

    Success breeds success. If you want to build momentum in your DevOps efforts, pick something that can be reasonably quickly achieved, that will also require collaboration. Set reasonable success goals and metrics, and then execute well against them. In my interview with IBM’s Dibbie Edwards on Standardizing Tools, Process, and Technology to Build DevOps Success Edwards stressed exactly that.

    “If you can get some good momentum under your belt with something that really has a positive impact, then it will get other people to buy-in,” she said. The example she used here was to reduce build times.

    Standardize on toolsets as well as processes

    Standardizing on tools comes with many benefits: lower costs, potentially fewer vendors to manage, and with fewer tools it’s also easier to cross train and integrate your development and management programs. But it also has a soft skill benefit, says IBM’s Edwards. “Standardization, or coming to a common way of achieving DevOps practices, is an important aspect because it gets people speaking the same languages. You’re able to have, then, a single version of the truth in terms of the viability of the project and where you’re going and you know that you’re communicating effectively,” he said.

    Over time, it’s central to these efforts to build standard processes, tools, and metrics so everyone is always on the same page.

    Build Empathy

    We hear a lot about the importance of empathy and DevOps. I think that’s a good thing. We need to be reminded at times that it’s vital that we try to see the world from the perspective of our customers and those we are working for. When it comes to DevOps, we are also talking about building empathy with those we are work with. “It’s all about effective empathetic communication,” said David Mortman is a recent interview. “Empathy is the killer app of DevOps. Many times we speak about the technical benefits, but the thing that makes all the stuff work is the ability to breakdown the silos. Break down the “It’s us versus them” mentality.”

    “Effective empathetic communication is also about creating a blameless postmortem-we’re looking at outcomes not blame,” Mortman said. “And making this about blame and coaches and tools and just getting to a place of “How can I help us all succeed.”

    Don’t push culture change for sake of culture change

    There is a lot of talk about the need for culture change as a central theme to DevOps. And building a collaborative culture is part of it, but organizations just don’t flip a switch and decree themselves a new culture. It takes the conversation, the momentum building, standardizing on tools and processes, and an understanding of the challenges and motivations of others on different teams. But it also takes good leadership, and training, and the right types of IT management incentives. Benjamin Wootton covered this in Why I Dislike the Term DevOps Culture. He goes into more detail about how taking affirmative actions will help to build and foster the collaborative culture the organization wants.

    That’s probably one of the most important considerations of all when it comes to building a culture of collaboration. Culture is something that grows from within the right environment; it’s not something that is implemented upon it.

  • Continuous Delivery and The Proof of Quality Assurance

    Continuous Delivery and The Proof of Quality Assurance

    Quality Assurance is critical in Continuous Delivery. Every change we commit to the common source repository is a release candidate. That’s why we test our code before we release it. We find out whether objectives has been met or not. Unfortunately, testing is a discipline that many try to avoid and it’s one of the main reasons for having specialized testers in the teams who know how to break the code best. But shouldn’t be the developers of the code know best how to break it?

    (more…)

  • GE Capital Releases Mobile App Twice Weekly, Automating Compliance at Velocity, Thanks to DevOps/CD/CI

    GE Capital Releases Mobile App Twice Weekly, Automating Compliance at Velocity, Thanks to DevOps/CD/CI

    GE Capital offers equipment leases, mobile apps, and financial products for corporate customers. GE Capital’s Matt Merchant, Global Managing Director—DevOps, spoke with devopsy.kinsta.cloud about development initiatives and processes at the financial services giant.

    According to Merchant, his team leads the charge in driving

    (A) the DevOps cultural transformation throughout IT,
    (B) the adoption and expansion of DevOps tooling, and
    (C) the change in governing structures in order to operate at a much higher velocity while continuing to meet regulatory requirements.

    That last mouthful speaks to a key pain point that GE Capital’s DevOps processes relieve: how to speed development while remaining compliant. GE Capital does it by automating security and compliance. You’ll read how shortly, but first, the mobile app.

    The Mobile App for Fleet Drivers

    GE Capital provides vehicle fleet leases globally for enterprises with delivery drivers, sales people, and others who travel on company business. The mobile apps that GE Capital provides as part of the leasing platform are many and vary from country to country. For this discussion, Merchant takes an app deployed in Sweden as the example.

    The web-based app enables drivers to locate nearby gas stations, tire shops, repair shops, and windshield replacement services. Drivers also use the app to download routes, to collect refueling, mileage, and oil change / service data, and to log their hours. The app creates a number of efficiencies.

    Drivers used to get shop data from a physical driver’s manual that they had to pore through to find the closest service provider. “The instant you hand them that catalog it’s out of date. Now they get real-time updates on their phones,” says Merchant. They also used to hand log their hours with pad and pen and then return to the office at day’s end to type this data into a computer. “Now they do it in real-time, and are done at the end of the day,” says Merchant.

    Mobile App Development Before & After DevOps

    In GE Capital’s old Waterfall mobile app development process, releases took six to eight weeks. Challenges included an inconsistent code repository, manual scripting and testing, and sitting before change, architectural, and security review boards every time developers evolved the code. “Because all that is so painful, you don’t want to repeat the process very often, and so you bundle more changes into a single release, which increases the risk of error,” says Merchant.

    With DevOps, GE Capital added Chef configuration management and created an “over-arching umbrella” development process that the company calls ArchOps. ArchOps covers CD/CI and virtualized cloud platform management while leveraging a Lean Six Sigma approach to swift Agile application development, explains Merchant. This enables fast iterations, consistent code, automated testing and, using Chef, fast VM spin-ups. And there are no more change management reviews.

    Achieving “Compliance at Velocity”

    To achieve what Chef calls “Compliance at Velocity” and deliver compliant, auditable code at a high speed, GE Capital reconsidered its toll gate processes and artifacts. “We applied a value stream map to our governance model, removing 60-percent of our toll gates and 70-percent of our artifacts,” says Merchant. This shrunk mobile app release delivery to days.

    GE Capital automated compliance by automating test output analysis. When the analysis shows that a portion of the code failed a test, the code goes back to development, which must fix it before retesting, further analysis, and eventual promotion to production. “That removed the need for a change advisory board,” says Merchant.

    And when an auditor requests test results, release dates, or copies of specific code releases, Merchant simply pulls the given code and all the test results, design artifacts, and governance data that are bundled with it from the Git repository and hands it over.

    Once Through Development, Please

    Now with a DevOps mindset in command at GE Capital, all developers use the Eclipse IDE, which transfers the code directly into the company’s Git repository. Once the code enters Git, developers can run jobs using tools such as Jenkins, do Fortify application scanning, and perform UI testing using GE Capital’s home grown tool called Rainbow.

    Once the code passes all tests, the system sends it into a pre-production staging environment. “GE Capital built the staging environment using Chef, which calls out to servers, spins up the environment, and places the code inside it,” says Merchant. User acceptance and remaining tests happen there. Then the Chef code that created the internal environment creates the production environment, ensuring application stability upon release.

  • 2015 State of the Software Supply Chain Report

    2015 State of the Software Supply Chain Report

    In April of this year, I embarked on a six-week journey diving deep into an analysis of the world’s software supply chains.  I evaluated the practices of 106,000 organizations, the 100,000+ suppliers they relied on, and the billions of software components that fueled their agile, continuous delivery and DevOps practices.

    The facts I discovered and share in the 2015 State of the Software Supply Chain Report: Hidden Speed Bumps on the Road to Continuous, (pre-register for the full release: Tuesday, June 16th) fundamentally changed the way I thought about software (and about DevOps).

    The volume and velocity of consumption, the variety of parts and suppliers, and the impact on innovation and quality astounded me.  Early reviewers of the report including Gene Kim (co-author of the Phoenix project), Gareth Rushgrove (Puppet Labs and DevOps Weekly newsletter), Nick Galbreath (Signal Sciences), and Nigel Simpson (Fortune 100 Entertainment and Media company) agreed.

     

    Screen Shot 2015-06-03 at 10.28.51 AM

     

    My aim for this research is not simply to present facts about the global software ecosystem.  I’m aiming to point a spotlight on software supply chain best practices within across a variety of industries that could be used as new benchmarks for software supply chain automation.  Similar to manufacturing of auto, pharmaceutical, healthcare, or defense systems, the effective management of supply chains will create winners and losers.  I’ll share evidence that the best, high-performance software development organizations are benefiting from:

    • Working with fewer and better suppliers
    • Relying on the highest quality supplies from those suppliers
    • Maintaining  traceability and visibility throughout the software supply chain for prompt and agile recall

    Key Points from the Study

    In the best organizations, the research revealed developer net productivity increasing by up to 40%. Just imagine applying that time to more innovation, rather than to rework and maintenance efforts.

    At the same time, the report touches on inefficiencies and complexities that are creating a huge drag on the velocity software development teams are aiming to achieve.  A lack of discipline, focus, and visibility around the software supply chain has resulted in mountains of technical debt, unnecessarily context switching, and outdated sourcing methods that wasted over 3.3 million build days last year alone.

    Hightlight: Automation Across the Software Supply Chain

    The other key insight from this research is the clear need for further automation across software supply chains.  With individual organizations consuming hundreds of thousands and sometimes millions of software components annually, it became obvious that waterfall-centric approaches to identifying the most functional parts, checking quality, validating appropriate licenses, or evaluating security vulnerabilities could not keep pace.  Sourcing practices that regularly go unchecked have also resulted in the use of severely outdated software components, even numerous versions of the same component part.

    Download the Full Report

    Over the next few weeks, I will publish excerpts of findings and best practices identified in the 2015 State of the Software Supply Chain Report and invite you to read along.  Or you can access the full report now through this link.

  • ProfitBricks shakes things up with new Docker hosting platform

    ProfitBricks shakes things up with new Docker hosting platform

    Organizations and developers that want to leverage Docker containers have a variety of cloud platforms to choose from. Rackspace, Amazon, Azure and others all support Docker containers. There’s also a relative newcomer in the mix looking to shake things up.

    ProfitBricks is an infrastructure-as-a-service (IaaS) company that believes it has a unique value proposition for companies that want to take advantage of cloud infrastructures and Docker container technology. ProfitBricks was co-founded by its CEO, Achim Weiss, and its CMO, Andreas Gauger. The two previously founded the Web hosting service 1&1 Internet.

    Weiss and Gauger launched ProfitBricks four years ago to solve a perceived problem. They saw the value of cloud infrastructure and cloud services, but felt that the existing platforms suffered in the areas of performance, flexibility, usability and cost. So ProfitBricks was born.

    ProfitBricks claims to have more speed and provide better value compared with rival cloud platforms. It calls its platform Cloud Computing 2.0.

    ProfitBricks Docker Hosting

    Docker has become a household name virtually overnight—quickly establishing itself as the de facto standard for container technology. David Bartletti, a principal analyst for Forrester, recently wrote in a research report, “Docker helps developers package code for quick assembly and hand-off to quality assurance, testing, and production release teams with greater confidence that their app will run consistently as it moves through the release process…The Docker open source community is growing quickly, with strong representation from nearly every major cloud vendor…As Docker containers proliferate, developers and operations teams alike will demand management tools that help organize and orchestrate hundreds or thousands of containers.”

    With so much momentum behind Docker and container technologies, it makes sense for a cloud infrastructure provider to integrate Docker into its ecosystem. Last week ProfitBricks announced its new Docker hosting platform. The platform features dedicated resources, redundant block storage, and 80 Gbps networking. It allows developers to choose images, link containers, and expose ports. The free tier offers customers 2,500 CPU Core hours as part of the Early Access Preview with up to 4 CPU cores, 8 GB of RAM, and 100 GB of storage.

    “When we first embarked on our Docker product architecture, we knew that it would not only need to meet the standards of existing Docker platforms, but also incorporate new, industry-leading features that addressed existing problems encountered with Docker,” said Achim Weiss, co-founder and CEO of ProfitBricks, in a press release. “Docker has been taking the DevOps world by storm since its widespread introduction to the community in 2014, and our platform will combine its impressive features with our flexible and painless cloud computing infrastructure.”

    ProfitBricks says that one thing that sets its Docker hosting apart from the competition is autoscaling. The ProfitBricks cloud infrastructure will ensure that resources are automatically managed to meet the demands of the Docker containers running on it. Developers don’t need to rely on standalone applications or custom scripts to scale resources because those capabilities are integrated seamlessly into ProfitBricks.

    ProfitBricks claims to be the best value in cloud computing. It offers a bold promise for the price / performance ratio on its site. “We guarantee that any workload deployed on ProfitBricks will cost less than the same workload running at the same performance level on the IaaS platforms of Amazon, Google or Microsoft.”

    You can check out the new ProfitBricks Docker Hosting for yourself. Visit this link for an Early Access Invite and find out if ProfitBricks can really deliver.

  • Follow the Unicorn: Transform your Enterprise Applications

    Follow the Unicorn: Transform your Enterprise Applications

    For those of us that work on Enterprise Systems such as the mainframe, the claims that the Unicorns (1) make, can be pretty astounding. Dozens and sometimes hundreds of releases a day from big companies like Netflix (2) and Etsy (3) are hard to comprehend. But look a little closer and you can see that the key difference is in the way changes are released to customers, not so much the total volume of changes. A traditional enterprise application may have thousands of changes made over the course of 3 to 6 months, but all of those changes are released at once. The Unicorns are typically able to release a very small number of changes at a time because they can develop, build, test, and deploy these changes very efficiently. Small batch releases to customers has significant value. It enables you to get feedback very quickly, and it is significantly easier to verify because the change is not mixed in with other changes.

    So how can you transform your development environment to deliver small batch of changes? I like to tackle the problem like any other computer science problem, no doubt because of my background. Break the large problem into a set of smaller problems and then solve those smaller, less daunting problems:

    Step 0: Start with a Proof of Concept

    Pick a Proof of Concept (PoC) to begin with that is important, but not mission critical. The PoC can be used as a learning ground and hopefully as a template for subsequent PoC’s. Make sure you have a team that culturally is willing to transform. Often the hardest issues to tackle have nothing to do with technology, but are cultural.

    Step 1: Understand your Application

    You need to have a good understanding of what your application consists of. Not only does the source code make up the application, but what source files are used, what the middleware configuration might be, what scripts you may have to build and deploy the application, and what data files (e.g. flat files, databases) that you use are also important. Some of these components may be shared with other applications, so you need to understand those dependencies as well. Once you have a good handle on the application, you can then automate the application build and deployment process so that all members of the team can work efficiently.

    Step 2: Understand your test cases

    If you can build and deploy the application quickly but it still takes days or weeks to test, then testing prevents you from delivering to your clients. An important shift for testing needs to be from testing the entire application to testing the change. You need to focus on running the right tests to ensure the change is correct and causes no regressions. Tests that do not exercise the code change are irrelevant and can be skipped. For many existing applications, the test suites may consist of hundreds if not thousands of test cases. Many of those test cases may be duplicates or testing areas of the code that are not being changed.

    Step 3: Understand your processes

    How fast can you get your updates to your customer? If your bug fixes and enhancements have to sit on the shelf for days, weeks or months before the customer gets them, they will not be satisfied. Streamline not only the development processes but the operations processes in your organization.

    To know more about the topic with the help of a real life case, watch the replay of a recent webcast which IBM in partnership with devopsy.kinsta.cloud hosted with Canada Mortgage Housing Corporation’s Jeff Blackadar on how breaking down IT silos helped speed up mainframe development for them.

    Also, do let me know your thoughts on the blog and on the topic.

    1 the born on the web technology teams

    2 http://www.slideshare.net/jedberg/devops-at-netflix-reinvent

    3 http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches

     

    About the Author/ Mike Fulton

    MikeFaceMedium-150x150A IBM Distinguished Engineer, CTO Enterprise DevOps at IBM,  Mike is a software development professional specializing in compilers, debuggers, profilers and virtual machines. At IBM, Mike works towards understanding and influencing trends and directions in Enterprise IT delivering new technologies into the DevOps Portfolio. He also overlooks integration of the DevOps Portfolio into IBM and Enterprise Software Solutions. Mike is an IBM Master Inventor with several patents to his credit.

    He is an avid blogger and regularly writes on his blog site – makingdevelopersliveseasier.wordpress.com

    linkedintwitter

  • Jenkins User Conference is a win-win for CloudBees

    Jenkins User Conference is a win-win for CloudBees

    The Jenkins User Conference and CD Summit US East, will be held in Alexandria, Virginia in a couple weeks. Gene Kim is one of the keynote presenters and the event includes an impressive list of sponsors, presenters, and attendees highlighting the momentum of DevOps. I spoke with CloudBees CEO Sacha Labourey—who will also be attending the event in Virginia—about the Jenkins User Conference, the growing Jenkins community, and CloudBees’ role in it all.

    Labourey expressed satisfaction with the growth and strength of the open source community involved in developing and maintaining Jenkins. It is the success of the community that both demands and allows for the Jenkins User Conference to be organized at locations around the world throughout the year.

    Continuous Delivery

    Jenkins is a platform for continuous delivery or continuous integration. The concept may initially have been targeted at developers but Labourey believes that the focus on continuous delivery is now higher up in the corporate food-chain. It’s now IT operations people and even the CIO and other executive leaders who are addressing the question, “How can we improve the delivery of software within the organization?”

    There is no single solution—no cookie cutter, one-size-fits-all way to do continuous delivery, though, according to Labourey. Every case is different.

    That’s why an event like the Jenkins User Conference is so valuable. Those considering Jenkins or exploring continuous delivery can learn more. Those already using it can share their own lessons learned and best practices. The community can collaborate and compare notes. By meeting and sharing companies and individuals can understand how other organizations are accomplishing things and take away the tips and advice that make sense and try it out for themselves. The cooperative nature of the Jenkins community is the fuel that drives it.

    Separation of church and state

    I asked Labourey to explain the relationship between Jenkins and CloudBees. CloudBees business focuses on delivering Jenkins continuous integration / continuous delivery for customers, so CloudBees obviously has strong incentive to ensure the success of Jenkins. He told me that CloudBees is a significant supporter of and contributor to the Jenkins open source project. CloudBees does not own or control Jenkins, though, and believes strongly in maintaining what Labourey called the “separation of church and state.”

    CloudBees has developers and engineers actively involved with Jenkins—contributing code and providing support. However, the Jenkins community organizes itself and manages the open source project without any involvement from CloudBees. The Jenkins community wants to remain independent and manage its own destiny according to Labourey.

    As noted above, though, CloudBees’ business relies on Jenkins. The stronger Jenkins is, and the better its features and capabilities, the better it is for CloudBees. That is why CloudBees has taken on the role of helping to organize and fund the Jenkins User Conferences. It’s a win-win because whatever helps the Jenkins community also helps CloudBees.

    Labourey promised that attendees of the Jenkins User Conference and CD Summit will not be disappointed. The sessions are filled with valuable content, and there will be discussion of recently added features and capabilities as well as the unveiling of some new ones. If you’re organization is using continuous delivery / continuous integration—or even considering it—you should check out the Jenkins User Conference.

  • CA beefs up DevOps offerings with Grid-Tools acquistion

    CA beefs up DevOps offerings with Grid-Tools acquistion

    After a relatively long hiatus from the M&A scene CA seems to be back with bang. Following on the heels of its nearly half a billion buy of Rally Software, CA yesterday announced the acquisition of Grid-Tools. Grid-Tools is a test data management market leader. Prior to the acquisition they were a partner of not only CA, but HP and Oracle as well.  Post acquisition it will remain to be seen whether HP and Oracle remain important partners.

    Taken with the Rally acquisition a week ago this buy makes a strong statement that CA is doubling down on DevOps. Of course Rally literally wrote the book on Agile and with Grid-Tools leadership position in its space, CA has in one week brought in two leading companies in their space.  As with any acquisition integration is always a question. In this case it is a double helix of integration. Integrating Rally with Grid-Tools and both into the larger CA portfolio will take some work.

    Last week I spoke to James Harvey, General Manager and SVP, IT Business Management Division at CA Technologies. One of the topics we spoke about was that CA in buying Rally was not only buying some great IP and products, but also getting some top people. The Grid-Tools acquisition brings another influx of new blood to CA as well.  On top of this CA also announced the appointment of Otto Berkes as CTO.

    Taken all together we get a picture of CA on the move. They are adding new ideas, new people and new products as they seek to transform from a software provider in the mainframe space to a major player in the new application economy.

    One of the things that I think we will also see CA move into in a bigger way is SaaS and services in general. Unlike many of its competitors, CA has remained a traditional software vendor for a long time. But with the state of technology today, offering software as a service and offering consulting services around the software is more and more a requirement rather than a luxury. This may cause some angst among CA service delivery partners, but I feel it is an inevitable step in CA’s market evolution.

    Another telltale clue will be CA’s ability to retain the talent at these acquisitions. All to often brain drain occurs after acquisitions. I have not seen any announcements around management teams staying on post-closing, but CA could use the talent. They have seen some executives leave recently.

    The real winner in all of this in my opinion is DevOps. Large technology providers continue to load up on DevOps offerings in anticipation of the larger global enterprise market adopting a new way of IT that includes things like Agile, DevOps, Cloud, SaaS, etc.  It also bodes well for future acquisitions in this space by CA competitors which should help make some VCs sleep easier about their investments in startups in the space as well.

    BTW, in the interests of full disclosure CA is a sponsor/advertiser here on devopsy.kinsta.cloud, though we had no special notice or insight into any of this news.

  • Gene Kim shares his thoughts on upcoming Jenkins User Conference

    Gene Kim shares his thoughts on upcoming Jenkins User Conference

    DevOps is coming to Virginia June 18 and 19. The Jenkins User Conference is being held in Alexandria and one of the keynote speakers is none other than Gene Kim—one of the original leaders of the DevOps movement. I had a chance to speak with Kim about what he plans to present and about his thoughts on the current state and future direction of DevOps in general.

    Kim told me he’s looking forward to speaking in front of the Jenkins User Conference audience. One of the core elements of his presentation will be a closer look at the principles and patterns of successful DevOps organizations and the lessons we’ve learned so far as a DevOps community. He told me he’s not interested in “unicorns”—the big name companies like Netflix or Facebook that were early adopters and DevOps innovators. He is more interested in the “horses”—ordinary companies effectively employing DevOps to do extraordinary things.

    Over the last year or two I have written a number of articles around the theme of DevOps being undefinable. I’ve asserted that there’s no default DevOps solution and that if you asked 10 different organizations to define what DevOps means you’d get 15 different answers. Gene Kim does not agree.

    Kim told me that he takes the completely opposite position—that there are unmistakable characteristics of DevOps. An organization can choose to call something DevOps, but according to Kim if it’s lacking in these core elements it will not succeed.

    He said that there are certain core principles that comprise DevOps and enable organizations to develop and operate faster. The principles Kim listed were peer review, less management approval required, rigorous automated testing, the ability to create entire environments on demand, and one-click deployment. Many of the core elements are a reflection of the culture shift required to successfully implement DevOps.

    Kim didn’t just pull this stuff out of thin air, either. He and some partners recently shared the results of a comprehensive study of 9,200 organizations scattered across 110 countries. The research revealed that the high-performers—those who have successfully embraced these core principles—do better than the non-high-performers by two orders of magnitude or better.

    Put another way, those organizations that are employing DevOps effectively are poised to blow their rivals completely out of the water. DevOps isn’t just a different approach to infrastructure or development—it has a direct impact on the bottom line. One part of the study found that high-performers have 8,000 times faster lead times than their peers. How can an organization that isn’t using DevOps compete with a rival that can produce 8,000 times faster than they can?

    That brings me to the other aspect of the Jenkins User Conference that Kim is excited about: the diversity of the organizations represented there. Both in terms of the companies represented by the presenters and the companies represented by the attendees, it’s apparent that DevOps has reached a critical mass of mainstream adoption. Organizations from Agilant and AirBus to IBM, Perfecto Mobile and Pivotal have respected professionals sharing knowledge about DevOps.

    If you happen to be in the Alexandria area or plan to be in a couple weeks you should try to go to the Jenkins User Conference. If you’re company isn’t using DevOps you’re already behind the learning curve. If you don’t catch up soon a competitor will out-perform you by two orders of magnitude and you won’t have a company anymore.

  • Top 3 DevOps Practices for Operational Stability

    Top 3 DevOps Practices for Operational Stability

    Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.

    (more…)