Category: Features

  • The Holistic Nature of DevOps, Architecture and Methodology

    The Holistic Nature of DevOps, Architecture and Methodology

    Throwing it Over the FenceDevOps

    DevOps…It’s become a term that has devolved to describe too many of the wrong things. Job titles like “DevOps engineer” and “Director of DevOps” and even DevOps training and certification programs hide an important issue of what DevOps was originally meant to be…

    If you’ve ever read “The Phoenix Project“, “Release It” or “Continuous Delivery“, (and you should) you probably already know that DevOps was never intended to be a title nor a department. DevOps is an organizational pattern. It’s what you get when development teams stop “throwing code over the fence” into production and start working together with IT operations personnel as members of cross-functional teams.

    Cross-Functional Teams

    Many so-called cross-functional teams usually consist of developers and testers; and sometimes even a business analyst or product owner. This is not what cross-functional means. True cross-functional teams include members representing the full spectrum of disciplines required to bring software from idea to production. Such teams include product owners, functional analysts, UX designers, developers, QA, DBAs, enterprise architects and IT Ops personnel, and these teams have full responsibility over all aspects of their software product until it is no longer in service.

    For many organizations, this is a bold departure from tradition in which development teams hand off completed software to a separate operations team for deployment and maintenance in production. The philosophy driving the DevOps movement seeks to eliminate this separation. But why?

    Handoffs are Wasteful

    Anytime the responsibility for a software product changes hands, even under the best of circumstances, some knowledge is inevitably lost. Additionally, each transfer of knowledge and responsibility along the production chain lengthens your product’s lead-time, incurring unnecessary costs. These costs might include time spent in meetings and writing detailed documentation instead of coding, plus delays in realizing revenue and ROI the longer your product takes to get to your customers.

    In Lean manufacturing and lean software development, any step in the process that moves unfinished product from one stage to another, making no changes to bring it closer to the state for which a customer would pay, is considered “waste of transport” – one of the original 7 forms of waste. One of the key goals of Lean is to reduce such waste, and one way to eliminate these handoffs is by having one team responsible for all aspects of the product. From the inception of ideas all the way into production—including bug fixes and production support—have one team communicating and working together all the way, making Conway’s Law work for you.

    Conway’s Law and Systems Architecture

    Over 40 years ago, programmer Mel Conway publicized his observation that the design of software systems reflect the communication structures of the organization that built it. This has since become known as Conway’s Law and recent studies have validated the idea.  The truth behind Conway’s Law is that, almost always, communication and activities in organizations follow the path of least resistance.

    For example, if the development team has to deal with too much red tape to get a database script into production, they’ll write a workaround in the application layer instead, which they control.

    This is also why most organizations in which development teams hand off code to ops teams wind up with code that is written well enough to pass acceptance tests in development and QA environments, but fail to take into consideration concerns like performance, security and scalability in a production environment. Teams that are structured to share information across departments and given autonomy to make decisions are better equipped to develop highly robust and cohesive systems.

    Not every team needs a dedicated architect, DBA, or Ops person. Depending on the needs of your organization, people in these roles can belong to multiple teams, providing much needed communication and consistency between their respective product teams and their departmental teams.
    In summary, organizing teams to be truly cross-functional, together with the application of Lean manufacturing principles, is how you can start to build a DevOps culture that will continue to deliver quality software for years to come.

    About the Author/Michael Ibarra

    Michael-Ibarra-devopsMichael Ibarra is a Solutions Consultant with AIM Consulting. A software craftsman, tech speaker and self-described troublemaker, he has been building software and development teams in the Seattle area for nearly 20 years.

     

     

     

  • ClusterHQ and devopsy.kinsta.cloud survey show Containers poised for mass adoption

    ClusterHQ and devopsy.kinsta.cloud survey show Containers poised for mass adoption

    devopsy.kinsta.cloud and ClusterHQ, conducted a survey on Container usage that shows an overwhelming majority of users have either already using, testing or investigating Container usage. With 285 respondents representing a wide range of organizations, it shows that Containers will be part of many production environments in the very near future.

    Currently, only 38 percent of respondents reported using containers in production environments, but that number is projected to increase 69 percent over the next 12 months as organizations find new ways to address important barriers to adoption. It verified that Docker is overwhelmingly the container of choice, with 92% of respondents having used or investigated it, followed by LXC (32%) a distant second, but still far ahead of Rocket (21%). To access the complete survey and report visit https://clusterhq.com/assets/pdfs/state-of-container-usage-june-2015.pdf.

    Companies ranging in size from small organizations with 1 to 500 employees (69%), to mid-size companies with 501-2,500 personnel (12%), all the way up to large enterprises with over 2,500 employees (19%) are represented in the survey. This demonstrates that containers are being embraced by all businesses from the startup stage to Fortune 500 companies.

    Respondents came predominantly from Development, Operations and DevOps teams. QA and security teams were a smaller share. The survey revealed how container technologies are being used today, as well as research-based insights while providing clues as to where the industry is trending.

    From the ClusterHQ release on the survey:

    The survey also revealed insights into what is perceived to be the primary barriers to container adoption. Security seems to be emerging as a consistent concern throughout the DevOps community in these times of never ending breaches throughout the world:

    • Security — 61%
    • Data Management — 53%
    • Networking — 51%
    • Skills and Knowledge — 48%
    • Persistent Storage — 48%

    Data Management capabilities also emerged as essential to the success of container strategies and that the vast majority of organizations want to run databases as well as additional services in containers.

    • When asked to rate how important data management is to container strategies, 66 percent reported it as a critical or important gating factor, 29 percent ranked it as moderately important and only 5 percent reported that it carries no importance.
    • Over 70% of respondents said they would like to run a database or other stateful service in their container environments.
    • Respondents were also asked which specific features of container data management they considered to be most important, selecting the “integration of data management capabilities into existing container workflows and tools” as their first choice, with “seamless movement of data between dev, test and production environments” a close second.
    • MySQL (53%), Redis (52%), PostgreSQL (50%), and Elasticsearch (43%) were reported as the top four most frequently used stateful services.

    Containers have become known for portability and flexibility, the survey reveals that organizations are using them in different infrastructures but most frequently in on-premises data centers (57%), followed by Amazon Web Services (52%).

    So I think it is safe to say Containers are rapidly becoming one of the staples of development and are here to stay to stay in the foreseeable future.

    devopsy.kinsta.cloud along with ElasticBox are currently conducting another survey on “What is DevOps to you?” One in 50 respondents wins a $50 dollar Amazon gift card and one grand prize winner will win a new 3DR Drone. Take a few minutes to help us with this survey.

  • 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.