Support & Downloads

Quisque actraqum nunc no dolor sit ametaugue dolor. Lorem ipsum dolor sit amet, consyect etur adipiscing elit.

s f

Contact Info
198 West 21th Street, Suite 721
New York, NY 10010
youremail@yourdomain.com
+88 (0) 101 0000 000
Follow Us
AutoRABIT Build vs Buy

Build vs. Buy, for a Salesforce DevOps Platform – Consider the Trade-offs

In the 1990’s evaluating a build vs. buy approach for a line of business system (such as HR or Finance) was sometimes considered a worthwhile use of time. But nowadays, with feature rich cloud-based systems, any executive considering building such systems internally would likely be asked “why aren’t we focusing our efforts on building customer facing applications rather than building non-differentiating operational systems”. Today, there are many cloud-based DevOps platforms on the market. So, for the rapid accelerating field of Salesforce based DevOps, whether it be for Apex or DX based development, decision makers need to consider a unique set, of often un-expected requirements, when considering build vs. buy. 

Since Salesforce development is different from traditional development, building a DevOps system requires an additional layer of complexity on top of any internally built (or an extended Jenkins) platform. This is because unlike traditional software development, Salesforce development is about managing changing object configurations, keeping sandboxes in synch, avoiding conflicts & efficiently releasing deployments without breaking Salesforce’s org structures. The level of effort to build these capabilities into a home-grown DevOps platform can catch many IT teams by surprise.

Arun Purushothaman, Salesforce development team leader at Land O’Lakes, went through a build vs. buy evaluation after they initially tried, but failed, to build a DevOps platform based on Jenkins. One of their key requirements, per Arun, was “to be able to keep sandboxes refreshed and be able to roll-back versions instantly”. In addition, Land O’Lakes needed to preserve parent child relationships when data-loading. He points out that Land O’Lakes teams kept investing in building their own platform, but deployments kept failing because “we weren’t able to address the ability to continuously synch sandboxes and we aren’t able to pre-validate developers code submissions”. Land O’Lakes eventually scrapped their admittedly cobbled together platform build efforts and proceed with a “purpose-built DevOps platform for Salesforce development.

Land O’Lakes experience indicates the high cost and complexity of trying to build Salesforce metadata awareness & highly synchronized capability into a home-grown DevOps platform. As more purpose-built Salesforce development support is built into a platform, the cost to build and maintain it goes up even higher.
Build vs Buy

A DevOps platform to support Salesforce’s org structure complexities must not only have all the foundational competencies of DevOps capabilities (found in hundreds of DevOps vendors’ platforms in the market today), it must also be able to: 

  • Parse & interpret Salesforce data structures
  • Spot only the delta changes within large Salesforce file structures & deploy incrementally
  • Identify destructive changes & provide an early warning system before org structures break
  • Monitor & gate every step in the DevOps process to ensure only the healthiest of codes is promoted to production
  • Keep Salesforce sandboxes in synch so a large development team can be aware of the most recent (delta based) changes
  • Automate otherwise manual steps (that are not Salesforce’s metadata API) during pre/post deployment phases
  • Be able to roll back destructive (to the Salesforce org structure) changes seamlessly
  • Proactively identify object dependencies in order to preserve parent-child data structure when loading data

 

Not only would such a build approach have to deal with the complexity of supporting Salesforce development (listed above), any one enterprise would also need to establish an ongoing relationship with Salesforce’s own product management team. They would have to monitor and keep up with changes to Salesforce’s platform roadmap and then perform major releases to their internal home-grown DevOps platform, each time Salesforce changes their platform. 

Needless to say, the time spent by an internal IT team’s building, monitoring and maintaining their own hand-built DevOps platform is time not spent building customer facing and business differentiating applications in support of their business needs.

Any organization considering a build vs. buy decision must face this time allocation trade-off.

Salesforce provided its Force.com platform-as-a-service (PaaS) so its customers IT teams could spend less time on building their service delivery stack (hardware, software, etc.) and more of their time focusing on developing business solutions. The same trade-off holds true for building vs. buying a Salesforce DevOps platform.

Post a Comment