As big proponents of software testing and deployment automation here at FrozenRidge LLC, 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.
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.
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.
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. Just shoot us an email.