devopsy.kinsta.cloud

Tag: Enterprise Development

  • Defining Value

    Defining Value

  • Git: One Giant Leap Toward DevOps

    Git: One Giant Leap Toward DevOps

    If you work in an organization that has not yet embraced DevOps, then you might be wondering where to begin. Fortunately, there are many good answers. But I want to introduce one simple starting point that you probably haven’t heard: introducing Git to operations. By itself, Git might not seem like a meaningful way to overcome the barriers between dev and ops. Yet, Git provides some capabilities that mark the difference between the lowest performing IT organizations and the highest. And the difference in IT performance can translate into substantial business benefits. The highest performing IT organizations have noticed the following benefits:

    • They are about twice as likely to exceed profitability, market share and productivity goals.
    • Their employees reported far higher levels of job satisfaction.
    • They realize 50 percent higher market capitalization growth over a three-year period.

    To be clear, no amount of data will ever prove that use of Git leads directly to growth, profit, productivity and job satisfaction. What the Puppet Labs’ “State of DevOps Survey” does show is the incredible range between low and high performance in IT organizations. The rate of deployment has hovered at 30 times faster for high-performing organizations over the lowest. The 2014 survey showed 50 percent fewer deployment failures, while 2015 showed 60 percent fewer deployment failures, when comparing highest to lowest. The survey also indicates which practices separate the highest performers from the lowest. According to the State of DevOps Survey, the top two indicators of high performance are:

    • Version control of all production artifacts (surprisingly, a far greater predictor of performance than version control of source code); and
    • Peer review of production changes (in contrast to external change approval).

    It’s not that these two practices magically yield business benefits. Indeed, ITIL has long recognized management of production artifacts and review of production changes as best practices. But too many organizations still believe faster deployment and higher reliability are trade-offs. What is “magical” in high-performing organizations is they realize they can have both faster deployment and higher reliability by collaborating across organizational boundaries and automating intelligently. That means dev and ops sharing goals, measurements and tools. So one way in which these practices differ from typical ITIL practices is how dev and ops perform them collaboratively. More specifically, when dev and ops use the same tool for version control, they can better share techniques and workflows. For example, the peer review of changes can include both dev and ops. Thus, Git is a gateway to DevOps.

    Git has long provided those two capabilities for software developers: Developers use Git to version source code and developers use pull requests to perform peer review of source code. With a few tips about how to apply Git to configuration files, operations can use pull requests to perform peer review of configuration changes. Now with git-lfs, operations can also version production artifacts, which often are large, binary files that historically have not worked well with Git. More advanced concepts such as infrastructure as code and dedicated binary repositories, for example, build on version control, so even if the role of Git changes over time, the skills and collaborations remain valuable.

    In summary, the business case of Git for Ops is simple. The Puppet Labs survey shows meaningful upside for low performing IT organizations to become high performing. The survey shows high performing organizations are characterized by both rapid deployment and high reliability, not picking one over the other. Two practices that characterize high performing IT organizations are version control of production artifacts and peer review of changes. Git is now well-positioned to provide both capabilities. If you’re ready to start introducing operations to Git, don’t forget that Bitbucket has no limits to the number of private repositories.

     

    About the Author/Ian Buchanan

    ianWhile Ian Buchanan has broad and deep experience with both Java and .NET, he is best known as a champion of agile methods in large enterprises. He is currently the Developer Partisan for Developer Tools at Atlassian, where he focuses on the emerging DevOps culture and the application of Bitbucket and Bamboo for better continuous integration and continuous delivery. During his career, he has successfully managed enterprise software development tools in all phases of their life cycle, from cradle to grave. He has driven organization-wide process improvement with results of greater productivity, higher quality and improved customer satisfaction. He has built multinational agile teams that value self-direction and self-organization. When not speaking or coding, you are likely to find Ian indulging his passions in parsers, meta-programming and domain-specific languages.

  • Tuning in to the real pain of customers

    Tuning in to the real pain of customers

    In my product management and marketing experience, I discovered that I carry a deep bias about our product capabilities and why it’s special — before a launch. On a whiteboard, in a spec, or in a usability lab, our product can and will change the world. Post-launch, when customers get their hands on our product, magical things happen. Intended use cases become irrelevant. Intended benefits change. Intended value changes.

    Over the past weeks, I’ve had the privilege of talking to many of our customers and prospects. They educated and helped me reframe the value we deliver to our customers.

    Real pain

    Much has been written about the DevOps revolution, driven by applications moving to the cloud, mobile computing, and the business need to compete. The journey to an agile build-test-release cycle is real, and it’s hard. It’s hard for customers who are cloud-born, and it’s even harder for traditional operations and development teams. Listening to our enterprise customers who are several years into their transformation, I heard a lot about the explosion of technologies and the cultural challenge. The pain of the change is more excruciating than I realized. One large customer told me that two years ago, he (VP of Cloud Operations) and his team couldn’t stand to be in the same room as the development team. Today, they’re collaborating to the point where they now sit together.

    Demanding developers

    Secondly, developers are more demanding. Again, it seems obvious, but hearing firsthand how hard it is to empower developers brings it home. Developers want and require more agile build, release and deployment capabilities, but they don’t want to be infrastructure experts. Enterprises are beginning to offer self-service to their private and public clouds so that developers can have autonomous access to environments and resources. A leading biotech customer told me that he can’t dictate policies and processes anymore, that he needs the researchers and scientists to adopt and embrace what the DevOps team is providing. Finding the appropriate balance between freedom and speed along with control is a common challenge across the board for our customers.

    Delivering value

    At ElasticBox, we talk a lot about the technology and cultural shift in enterprise DevOps teams, and how we can enable greater collaboration by being at the nexus of the transformation. That is what we ultimately deliver to our customers: a new way to deliver applications to the cloud that’s better, faster and more efficient.

    It’s a big promise, and we’re excited to fulfill it. Today, we deliver the foundational tools for self-service provisioning, service catalogs and continuous integration and delivery — wrapped with a flexible box architecture that’s reusable and agnostic to the underlying infrastructure and deployment tools. We approach the problem from a developer mindset to drive speed and autonomy, and at the same time, provide the policies and reporting to ensure scale. We’re hungry to continue learning from you, so check us out and let us know how we can help.

  • Does DevOps spell death for Line-of-Business (LOB) Applications?

    Does DevOps spell death for Line-of-Business (LOB) Applications?

    Perhaps wrongly, “DevOps” has been associated with “new” and “that thing for the cool kids” and the “hipster developers”. This is used both as an excuse and as a source of animosity against the movement. But more subtly, I sometimes observe IT departments that acknowledge DevOps as a thing, but claim it wont work for their applications. I always pause and ask: What are the applications they are referring to, and are they correct?

    (more…)