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.
