DevOps: Build Versus Buy
DevOps: Build Versus Buy
The choice of constructing your own solution or purchasing a pre-built tool might seem easy...until you look at all the factors.
Join the DZone community and get the full member experience.Join For Free
Rapidly provision TLS certificates from any certificate authority within your DevOps CI/CD pipeline. Speed up deployments with automated TLS certificate provisioning using your existing DevOps toolchain.
Is the DIY Solution Truly Less Expensive?
Selling DevOps tools to developer organizations is a unique challenge. The users of these tools can write their own from scratch or piece together open source to do the same job. But just because you can, doesn’t mean you should.
This article looks at the challenges of building your own DevOps tools in the Salesforce Ecosystem and shines a light on some of the hidden costs of DIY.
The first 80 percent of most software projects is usually easy for a seasoned developer. The open source tools were built by developers for developers and typically use scripts to stitch together the pieces and parts. So most Dev teams are accustomed to enhancing and extending the tools they already use. The challenge is always in the next 15-20 percent.
Open source tools are generally pointed solutions, built to solve a single narrow problem. Creating an end-to-end solution typically means you will need a collection of disparate tools cobbled together with scripts. Often they are written in different languages with very different styles making it more difficult to extend than a single comprehensive solution.
If you are relying on tools for production development with large teams and they don’t do everything you need, then everyone will be working around those gaps every day. You may be willing to overlook a little cludginess, but will all of your team mates? What will it take to fill in those gaps?
Salesforce is Unique
Adding to the challenge is the uniqueness of cloud platforms and Salesforce in particular.
The Salesforce platform is different in many ways from traditional development. There are features from Salesforce that aren’t quite complete yet. For example, the Metadata API does not provide 100 percent coverage.
Using Git to merge Apex code works well, but using it to merge the XML structures like the Profile, Permission Sets, and Page layouts is challenging. You will need to parse these structures and extract the changes yourself.
Learning all of the gotchas and their workarounds will take years.
With Salesforce, what is the definition of “built” when it comes to automated release management? Does it include pre- and post-deployment steps for example?
If you build 80-100 percent of a smaller vision, is it really as valuable as 100 percent of a larger offering?
So you’ve found a way to make your existing DevOps tools work with Salesforce. Unfortunately, the Spring 19 release will be hitting production in February 2019. Have you tested your tools with the new features yet? You can still use the current version of the API for the foreseeable future, but what if your development team needs to use the new features introduced in the next release? Or in Summer 19? They do three releases a year, right?
Then there are the game changers like DX. Scratch Orgs, Org Shape, Dependency API, and Org Snapshots will make DX even more powerful than the traditional sandbox development approach. Are you up to speed on all of these new features? How much effort will be required to update your homegrown solution to accommodate them?
Does your tool integrate with Jira and Bitbucket? Azure Devops? They are not standing still, either. And what if your team decides to move from Bitbucket to GitLabs? Will that require a lot of change, or will you simply decide NOT to make the move. Will you be locked into your current set of tools because of your DIY solution?
Usability Across Teams
Will the other development teams in your company all use the same process and tools? Has the compliance organization approved your tool? Do you save all of the information that they require so you can track who made what change and when?
Segregation of Duties is a best practice of DevOps. Release Managers and Developers should not have the same level of access to customer- and employee-facing environments. This requires that your DevOps tools are built with Access controls in mind. The Salesforce platform has native features that makes this easy, so your DIY solution should include these concepts as well.
If your company is like most, there are never enough developers to do all the work that the business needs for your core processes and products. Every hour you spend fixing an issue with the homegrown developer tools is an hour that could be spent on a feature for the business.
Setting up a DIY solution will not bear fruit until the end of the period, be it 6 or 12 months later. Buying a solution means productivity immediately.
While it seems like building your own tools or stitching together open source will save a lot of money, the reality is much different. Commercial tools result in productivity gains for all of your team members. They enable you to switch out to new tools when it makes sense for your organization. Salesforce DevOps companies spend all of their time thinking about and incorporating the new features of each Salesforce release. They track the updates to all of their integrations and ensure everything works as expected. They build in the compliance requirements for Financial Services and Healthcare companies, so even if you are not in these industries, you will benefit from the audit features they provide.
So while you may have started out building these tools for your own use, are you really happy now that they have made their way into your production flow? How much of your team’s time is spent maintaining these free tools? If you really add up all of the hidden costs, you will likely find that free is much too expensive. Invest that money in commercially available tools from a reliable vendor and spend your time working on your company’s core business problems.
Opinions expressed by DZone contributors are their own.