The first thing most of our customers ask is what tools they should invest in. With a sea of solutions out there, it can be challenging to identify the right DevOps tech stack. Before you define your tooling, it is important to establish the business outcomes you want to achieve and prioritized them against project inputs and ROI. Once that is done, you’re in a good position to evaluate tooling.
Select Tools Based On Requirements
Selecting tools that meet your requirements may sound like an obvious statement but very often we see people select a tool based on buzz rather than business requirements. For example, choosing to set up a kubernetes cluster and then deploy Jenkins-X may seem like a good idea but if the requirements is to build and test pull-requests for a few repositories it’s probably overkill.
Do a Proof of Concept
Once you’ve listed out the requirements of the tooling, you should pick a few options and implement a small POC on each to test the validity of the solution. This will also help you to understand what potential issues will be encountered when onboarding new users as well as what maybe be involved with supporting a self-hosted solution.
Paid vs Self Hosted
When selecting tooling it’s important to evaluate paid solutions as well as self-hosted, open-source solutions. Often a paid solution can help you minimize setup time, onboarding and maintenance allowing your team to focus on delivering features and customer satisfaction.
The Case Against Self-Hosted Solutions
Any CI/CD tooling that your team is going to deploy and manage needs to be treated as a service that your team is providing to customers. That means all of the things that go along with supporting a product will be the responsibility of the CI/CD team.
This may include any or all of the following:
- Support with onboarding and any issues
- Adding build dependencies
- Upgrades to the software
- Uptime Monitoring
- Responding to outages
If the expected use of the tooling is high or will grow to be high, these items will end up consuming more and more time.
The Case for Paid Solutions
Paid solutions, like ShuttleOps, are a good way for DevOps teams to reduce the burden of supporting an internal product by leaving the responsibility of maintaining a product to the vendor. In many cases, a paid solution that meets your requirements can save you many people-hours, and allow you to focus on your core business instead of your internal tooling.
Community & Documentation
Lastly, if you’ve found the right tool that meets your business requirements, it is important to evaluate the documentation and community around that tool or product. Proper documentation and a strong community can be invaluable in increasing the adoption of an internal CI/CD tool and also help relieve the burden of support on the DevOps team. A good way to gauge this is by, again, doing a POC since you’ll probably rely on the documentation to help you set it up. Also, consider if they have a slack/gitter community or a forum to post issues that require more help.