devopsy.kinsta.cloud

Tag: codeship

  • CloudBees Acquires Codeship to Extend CI/CD Reach

    CloudBees Acquires Codeship to Extend CI/CD Reach

    CloudBees today signaled its DevOps ambitions to extend well beyond the Jenkins continuous integration/continuous deployment (CI/CD) platform by acquiring Codeship, a provider of a CI/CD platform that is delivered as a software-as-a-service (SaaS) application.

    The decision to acquire Codeship is being driven by the need to engage smaller DevOps teams that don’t have the time or expertise required to set up on-premises instances of Jenkins, said CloudBees CEO Sacha Labourey.

    Codeship today is being used by more than 100,000 developers spanning 2,400 customers. Many of those developers are working at smaller companies. But Labourey noted that small teams of developers inside larger companies also prefer to invoke a CI/CD platform as a service.

    “Different teams will decide to do different things in the same organization,” said Labourey.

    The Codeship platform is not based on Jenkins and there is no plan to rehost the Codeship service on Jenkins, says Laborey. Jenkins is designed to be highly customizable by the organization that employs it. The Codeship service is a highly opinionated instance of multitenant CI/CD platform that is designed to provide a turnkey experience capable of support lots of developers at once, explained Labourey.

    CloudBees will explore ways to bundle its core platform with the Codeship service for organizations that find themselves needing to deploy both a CI/CD platform on-premises in addition to a cloud service, he added.

    The acquisition of Codeship signals a wave of coming consolidation across the DevOps sector, Labourey said, predicting that over time, a much smaller number of companies will account for most of the DevOps software and services sold. Some will rise from the ranks of the pioneers of DevOps. Others will be the same companies that today dominate application lifecycle management (ALM) and software development lifecycle (SDLC) software in the enterprise. As DevOps continues to gain momentum in the enterprise, it’s now only a matter of time before legacy ALM and SDLC vendors are forced to modernize their portfolios by making acquisitions or partnering with companies such as CloudBees, he said.

    It’s too early to speculate how that consolidation might play out. But it’s clear the rise of microservices is about to force the DevOps issue in many enterprises. The rate at which DevOps processes have been adopted across enterprise has been uneven, but as organizations embrace microservices to build better applications faster, many will need to re-engineer their application development processes. There always will be monolithic enterprise applications that may be better-served by waterfall approaches to application development, but in time, the bulk of applications will be built employing microservices architectures that make it easier to update and manage applications employing modern DevOps best practices.

    How much those DevOps processes will be based on CI/CD platforms running in the cloud or on-premises is anybody’s guess. More than likely, most organizations will rely on a combination of both, depending on the size and scope of their efforts. Regardless of the approach, however, at a time when every company is becoming more aware of their dependency on software to compete, it will be those organizations that embrace DevOps processes best that will prosper at the expense of rivals.

    — Mike Vizard

  • An Even More Modern Continuous Integration

    An Even More Modern Continuous Integration

    It would be strange for me to tell you that there is an even newer new approach to release automation, as if the processes of continuous integration (CI), continuous delivery (CD), continuous deployment and canary releases were not modern enough. And it would be even stranger to say that the open-source tool Jenkins, which dominates more than 60 percent of all release automation processes, is not enough for some, according to Salesify. But right now, I’m going to make the claim that all of the above is true.

    DevOps teams are impatient. They always want better. It is part of the enthusiasm that continuously pushes the modern delivery chain forward. But, of course, this change has to be throttled. This is why I look to companies who have found the proper mix of sustainability and modern tooling. When I met with TapInfluence, I was surprised to find out that even the “modern” tools of 2015 are not enough for the demands its applications are putting on application releases. And its new delivery chain is a powerhouse for releases and quality.

    Tapinfluence is a SaaS platform for initiating and managing influencer marketing campaigns. The company has 60 employees and growing with engineering based in Mountain View, California, and HQ in my home state of Colorado. Up to this point, the application has grown organically from a minimal viable product (MVP), which was driven primarily by a stream of requirements that came up and then adopted, to an established web application built on modern development principles. The incremental improvements are in the spirit of modern development, but it did not make for a sustainable delivery chain—or a delivery chain at all. The company lacked the practices of release automation and infrastructure you would expect.

    That is why when Tapinfluence raised its latest round of funding, it was not only meant to grow sales and marketing. The funding was also intended to build a more mature development operation to keep up with the growth of the platform and make sure all the new functionality did not come with technical debt.

    Kabriel Robichaux became the first director of engineering, and boy, did he have a lot of cool stuff to bring with him. Nearly from day one, Robichaux was preparing for team growth (from four to an estimated 20 team members in the next year), and significant changes to modernize the infrastructure and processes in the existing development team. This included Docker and a new release automation tool called Codeship. It was Codeship that got my attention.

    Robichaux had a lot of experience in releases automation already. “I have lots of experience with Jenkins, but working in a startup, a hosted CI solution was a key feature.” But, of course, cloud-based is not the only thing. After all, you can put Jenkins in your own cloud fairly easily.

    But Robichaux’s top considerations went beyond the purely technical and into their relationship to the community. He explained to me that when he adopts tools, he finds alternatives to the most popular tools, and checks them all out. He looks at tools from not only the perspective of their core functionality, but also whether they are committed to growing the market.

    So we’re not talking about a new generation of release automation. Release automation is just a workflow tool. It is how the tools approach the market. And it is a tremendous coincidence that he works for an influencer marketing company, and made a deliberate choice to look at how Codeship influenced the market. “I loved Codeship because they have an opinion, they are consistent with it, and they share it. For example, they believe that everything should be in source control, and so do I.”

    Considering that I work for a company rooted in developer communities, I have seen this social aspect of tool adoption as well. And it is growing rapidly. Given all the noise, it is not enough to have one or two features that do things better than the other guy. You have to be something more than a product or brand. Getting back to tactics, full control as also imperative.

    He said, “I need to be able to customize everything without jumping through hoops. I want to launch it, get to the terminal window, and start adding steps. The release automation tool, if working properly, should be transparent. I want to focus on the steps in the process, not how to run the tool.” Showing that he understands that there is an effort cost in utilizing and being an expert in a tool, which should not be required.

    The other element of a modern release automation tool (assuming you are on the bandwagon of the container-driven pipeline), is the container-native status. Codeship and CodeFresh, two relatively new tools, are both hanging their hats on container-native applications, and assume you are running your application on containers and/or microservices.

    Tapinfluence is one of a handful of paying Docker customers. And they are taking it one step further than most by Dockerizing their entire development environment. “In 30 minutes, someone could go from having nothing on their machine, to a full dev environment and ability to commit and deploy,” Robichaux explained, which is critical, as he not only has to support the core development team, but also data scientists who know how to code, but do not know the ins and outs of the application or how to create a build they can work against.

    “Normally it would take three or four days of training to get someone up and running,” Robichaux said. Given the pace of the changing environment, he simply can not waste time getting new devs going.

    Tapinfluence’s application runs on AWS, and it uses Convox to manage both its developer and production instances. As he said above the source repository is key, and Git is central to everything. Git is where all the vetted Docker Compose files are stored. The DevOps teams vet the core images, and developers manage the delta for the particular service they are working on. The net result is a unified delivery chain that can do a release within five minutes.

    If I were to speak with Robichaux even a month from now, I would likely be shocked again at the amount of change his company has gone through. But, it is keeping an application up and running and delivering the results its customers expect.

    In the true DevOps spirit, the goal should always be to push the needle toward faster, more frequent releases at a higher quality. If you stagnate with one stack, you will not be a DevOps environment by the end of the year.