Current State of Continuous Deployment and Continuous Integration Tools

As big proponents of software testing and deployment automation here at , we’re constantly thinking about how best to improve the testing process. More than anything, it should be fast, easy, and customizable from project to project. That’s been the philosophy behind our own Open Source testing tool, StriderCD.

However, we’ve noticed that the continuous integration and deployment tools available right now are generally geared towards a specific need, rather than a variety of use cases. If it suits your current project, that’s all well and good, but what about the next project and the next? Without CI and CD tools that can change along with testing requirements, our jobs are made just that much more difficult.

The Method Behind Continuous Integration and Deployment

Underlying CI and CD is test-driven development (TDD), which relies on continually writing test cases along with your code. Emphasizing simplicity and functionality, the hope is that TDD makes you more productive in the long run.

Testing doesn't solve all our problems, of course (i.e. overtesting, compliance testing, etc.). Still, it does save us time by catching bugs and defects in the code early on, rather than having to dedicate resources down the road in time-consuming debugging tasks. The modularization that testing encourages also helps us build code that’s more extensible and easily integrated with other code and programs.

Continuous Integration comes in whenever new changes and commits are made, running tests and tracking changes on each commit. Then, Continuous Deployment automatically deploys successfully tested commits to production. In both cases, the really difficult part is having a comprehensive and well-maintained test suite, as well as a fast and reliable automated deploy process. CI and CD are both useless if there’s little or no discipline for writing and maintaining tests.

Open Source and Closed Source CD/CI Tools

Jenkins and Travis are probably the most well-known Open Source solutions, though comparing the two is a little like comparing apples and oranges. Jenkins is an enormous, complex piece of software that needs its own server, which doesn’t make it a great tool for smaller teams and individual developers. Although Travis updates in near real-time, is cloud-hosted, and can test against a variety of environments, its focus is primarily on CI rather than a combination of CI with CD.

StriderCD works on the same concept behind Jenkins and Travis and tries to improve upon it, focusing on continuous deployment as well as continuous integration for web applications. It runs tests (both server-side and front-end) and deploys automatically in response to GitHub commit notifications. Strider is easy to setup and comes with out-of-the-box support for projects in Node.js, Python, Qunit and Selenium/Sauce Labs tests. What really sets it apart in our minds, though, is Strider’s extensibility through plugins. As long as you know JavaScript (and who doesn’t these days?), the plugins are incredibly easy to write and install. This makes customization a breeze rather than a headache.

Some of the more well-known hosted, closed source CI tools include CircleCI, Cloudbees, and Wercker. All of them support the major frameworks, mostly differing in the details. Cloudbees is essentially Jenkins-as-a-Service; CircleCI is very similar to Travis, though it does emphasize continuous deployment; and Wercker is still in beta. The problem with all of these solutions, however, is that they can’t be customized. They may be flexible and they may allow you to “create” your own drag-and-drop dashboard, but they’ll never look exactly the way you want them to look.

Advantages of Open Source Over Closed Source Tools

The wide availability of continuous development and continuous integration tools right now makes utilizing CD and CI compelling. At the same time, customization and integration with existing systems isn’t quite where it should be in order to meet the changing needs of most development projects. While there are plenty of options when it comes to hosted and closed source CD/CI tools, they lack the flexibility and extensibility nearly all of us need.

It’s probably no surprise that we advocate the Open Source route. In our estimation, Open Source tools like StriderCD present a better way to manage test-driven development/CI/CD because they’re easier to customize and can be self-hosted. Obviously, having the ability to do that is a huge advantage over the restrictions that occur with closed source products. Open Source allows you to customize your testing process on the fly and integrate new processes where needed, rather than having to make do with the processes already built into a closed source solution.

The problem with CI/CD tools right now is that they mostly focus on one thing. They just can’t serve a wide variety of use cases over time. Our goal with Strider is to make the testing and deployment process as easy as possible by focusing on customization and extensibility. By making it Open Source as well, anyone can customize it to meet their specific testing needs.

If you’re looking for a great system for tests, builds, and deployment, we’re here to help.