Whitepaper CI solutions vs - AutoRABIT · CI solutions ... has no release or change management...

®

Salesforce Release Automation

vs

Whitepaper

AutoRABIT

CI solutions

Copyright © 2016 AutoRABITwww.autorabit.com | [email protected]

Continuous Integration (CI) often means different things to different people.Let’s start by agreeing on a single definition of CI as a reference point.


2

With a healthy fourteen percent of the CRM market, Salesforce is a widely known and respected cloud based customer relationship management (CRM) application. As the Salesforce application grew in popularity demand for functionality increased. Providing all this functionality on a timely basis was neither feasible nor sustainable. Enter in Force.com, a cloud based platform for building custom applications in the Salesforce environment.

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. The goal of CI is to provide rapid feedback so that when defects are introduced into the code base, they are identified and corrected as soon as possible. Achieving Continuous integration includes automated version control, deployments, and testing -- all the while building a document trail.

When CI works well, it helps the code stay robust and automates the development cycle. This speeds the flow of development work overall. Automation dramatically reduces the amount of time spent managing the code developers have written throughout the process.

Continuous integration works well for typical software development but struggles with cloud environments such as Salesforce.

As convenient as Force.com might appear, it is not without its challenges. Force.com uses Apex code, a proprietary language from Salesforce. ‘Out of the box,’ Apex comes with few tooling options and can be cumbersome to develop on. If you have worked in the Salesforce (SF) environment you are likely familiar with these challenges. If you haven’t here’s what’s in store:

Manual deployment The deployment process in Salesforce is still fairly manual. While this situation is slowly improving, developers that have worked in automated environments get easily frustrated with the level of manual tasks required. For instance, after a production release it is necessary for developers to perform pre-refresh and post-refresh. Since SF has multiple release environments such as System Integration Testing (SIT) and User Acceptance Testing (UAT) they are cumbersome.to manage. Refresh tasks are predominantly manual and complex.

Out-of-Sync Environments SF does not provide version control software or any means to synchronize developer sandboxes, release environments and production orgs. There is no capability to maintain version changes, track them or synchronize “hotfixes” made in a production environment downstream. Typically, multiple development teams code and commit in parallel, resulting in massive code overwrites and loss of productivity.

Migration within Salesforce Orgs Salesforce environments are known for being large and complex. Typical deployments contain a few thousand members or more, including large custom objects, profiles and permission sets. Attempting to manually manage pre-migration and post-migration is cumbersome and labor intensive. An automated and scalable data loader is needed.

Maintaining Governance and Audit standards Common development practices incorporate code releases in parallel. Salesforce has no release or change management functionally, limiting governance and auditing capability.

Exclusion Lists in Deployment Security guidelines often require selective metadata to be excluded in packaging and deployments. Examples include login IP ranges and SSO configurations. Within the SF environment there is no way to selectively deselect metadata without heavy manual intervention.

Developing on the Salesforce platform

Challenges with developing on Salesforce


3

Understanding Salesforce (SF) continuous integration best practices can be challenging. With the multiplicity of processes and the plethora of tools that are available to support this rather complex process, choosing the right solution is critical for streamlining, automating and making your release process more manageable. To help manage challenges with SF development, developers typically turn to well-established and well-known continuous integration solutions; some homegrown and others vendor-provided. In this paper we will examine both options.

How are developers managing Salesforce development challenges?

Frequently, Force.com developers go down the path of building their own Open Source solutions with open source tools. The open source route is popular among developers but has significant challenges that impact the total cost of adopting this approach.

Foremost open source solutions are free to acquire and use. However, in the final analysis, it is rarely cheaper to build a Open Source solution than to acquire a third party vendor solution.

Here is the rationale -- third-party vendors have a team of architects and developers dedicated to product development, bug fixes, roadmap investment and configuration for deployment across environments. For a third-party vendor these development costs are spread across an entire customer base, unlike open source development where development costs are absorbed by one enterprise. For an open source team to build a functional CI product on Force.com they must employ specialized teams of architects and developers to build custom scrips and to maintain and evolve the software. These investments are very expensive and typically increase the total cost of ownership over licensing third party software.

A given open source CI solution will require over ten (10) different tools be integrated and supported on the Force.com development platform. There is also the continued investment to support upgrades and evolving requirements. By way of example, the one of the most widely used tools for CI is Jenkins. It’s a great tool for typical software development such as Java, Ruby and .Net, therefore Developers often default to Jenkins because they are familiar with it and expect it to work for SF development and attempt to morph it to the Apex world. Again, Apex is a SF priority language and comes with very little tooling options. Jenkins is not specifically designed for Apex, therefore requires custom scripts be written to access metadata. In short, to morph Jenkins into a highly functional and scalable Apex compatible solution requires significant ongoing engineering investment by the enterprise, often with disappointing results.

Let’s dig a bit deeper into Jenkins and explore its ability to implement CI within the Salesforce environment.

Open Source solutions … the right approach?


4

Aside from being familiar with Jenkins, developers choose it because it’s free and has a large plug-in library that can be used across various platforms. As mentioned above, once developers start to use Jenkins on Salesforce they quickly realize it’s not built or optimized to function properly. The following provides more specifics around challenges with Jenkins and Salesforce:

Does not facilitate code check-in Checking in code is a major part of the CI process and also a big pain point for SF developers. Jenkins does not support version control to sandbox deployments or have a check-in editor. Check-in editors make it easy for teams to seamlessly and frequently check code into version control systems. With Jenkins, a Salesforce developer checking in code must perform five or more manual steps. For instance, a developer needs to move code from a developer sandbox to an eclipse editor, install plugins and refresh from the salesforce sandbox into a file system. All this enables you to select changes and manually move them to a version control tool. Developers must also be proficient in the use of the underlying version control tool.

Jenkins does not have a merge Editor Salesforce developers cite merging complexities as a major challenge. Similar to the lack of a check-in editor, and particularly within a browser environment, the lack of a change editor requires the task to become manual.

Jenkins requires customized scripting effort (Testing) To deploy Jenkins in SF a developer must write scripts that package metadata into a SF deployable format. Further, developers need to write scripts to run tests in Jenkins because it doesn’t support Apex testing; it only understands Junit, .NET unit testing and other open source testing platforms. And, to commit code into a version control tool Jenkins requires the development of a URL connector that pulls all Java and .NET changes - more script writing.

SF governor limits Salesforce restrictions include 10,000 records and up to 400 mb of data. The governor limit is Salesforce’s way of ensuring that developers write efficient and scalable code. Governor limits are more challenging to manage with Jenkins. Specifically, the limit requires developers to separate members into batches of 10,000 records and to check for dependencies to ensure a logical deployment, all of which is a manual process. Furthermore, Jenkins does not support selective deployment capabilities, again a manual effort.

Data migration Data migration is problematic in that Jenkins only supports application deployment; there is no support for data and metadata migration. It also lacks a seamless process of data migration between orgs and sandboxes.

Tracking Governance and Audit for Deployments Teams using Jenkins encounter many challenges tracking and accounting for changes made by developers because it lacks tracking capability. Any traceability resides at the code level which needs to be provided by the version control tool being used.

Overhead SF’s cloud architecture eliminates expensive software infrastructure for its customers and is the primary reason for its success. Regarding Jenkins’ architecture you can either download the desktop version or access their cloud. If by way of desktop version, additional cost might be incurred for physical hardware, the installation and setup of a version control repository. If accessing the cloud version may incur additional cost for setting up and using the instance. Support would also be additional cost. Both services would require the development of custom scripts.

The Jenkins example … can it work with Salesforce?


5

Literally, it’s all about the details. Any decision maker needs to consider a solution’s ability to execute on the following functionality, at scale:

AutoRABIT is cloud based Continuous Delivery product specifically designed for Salesforce. AutoRABIT helps developers and admins by automating the development processes like version control, deployment, test automation, sandbox management & data loading and achieve Continuous Integration and ultimately Continuous Delivery (CD).

Before moving forward, let’s take a moment to under a few definitions in regards to Continuous delivery and DevOps

Continuous Delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centers around the cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery. Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently. Thus, DevOps can be a product of continuous delivery, and CD flows directly into DevOps.

Relationship to continuous deployment. Continuous delivery is sometimes confused with continuous deployment. Continuous deployment means that every change is automatically deployed to production. Continuous delivery means that the team ensures every change can be deployed to production but may choose not to do it, usually due to business reasons. In order to do continuous deployment, one must be doing continuous delivery

AutoRABIT is purpose built to execute a best practice based CI /CD solution on Salesforce.

At its core, AutoRABIT’s CI server provides a cloud based, completely integrated and automated CI/CD environment. The entire CI/CD process is managed through AutoRABIT’s GUI based UI, which abstracts complexity of the underlying tools that are integrated. Developers execute the CI/CD process through one UI, eliminating the need to be trained up and proficient on all the underlying tools. With AutoRABIT, SF development teams reduce time spent on managing the code they write by 70%, achieving higher release velocity and quicker time to market. And, the total cost of ownership is lower than patch worked open source alternatives.

Version control - implement and maintain a source code repository, easy code check-in, branch merging, tracked changesAutomate build and deployment, eliminate change sets and limit pre/post manual steps, selectively deployAutomate testing - test on multiple sandboxes and data sets at scaleSandbox management – ability to keep all sandboxes in sync across Salesforce orgs; conflict resolution, reduce need for refreshes Data loading and management – high volume data loading (eliminate use of CSV files or manual steps, circular reference resolution)User friendly GUI with centralized reporting and controlsSolution that supports CI best practices across an integrated development and release environment

Considerations for selecting a Salesforce friendly CI Solution

Introducing AutoRABIT


6

AutoRABIT is integrated with over 70 leading development tools that span the complete development and release cycle. Tools are integrated and managed by the AutoRABIT CI server which is specifically optimized for scale on the Salesforce cloud.

Enterprises look to AutoRABIT when they are struggling with the following challenges:

Version Control adoption and management Out of the box AutoRABIT quickly integrates (24 hours) with all leading version control systems (such as SVN, TFS, Perforce and all types of GIT).

Check-in editor A check in editor that simplifies code check-in down to a click of a button. The check-in editor shows changes, selects the changes developers want and commits to version control.

Auto-commit changes Supports auto-commit changes from each Salesforce developer into version control, eliminating the risk of code overwrite.

Track changes Visibility into all changes made across all sandboxes. Change analysis functionality tracks details of authors, modifications / additions / deleted files, line(s) of code modified by object / file and detailed reports.

Supports Salesforce “Quick deploy” functionality Quick deploy is a SF feature that allows developers to deploy components into production by skipping all Apex tests for components that have been validated within the last four days. Developers no longer wait for all tests to run before deploying components into production and can reduce deployment time to 30 minutes. AutoRABIT is the only solution that supports Quick deployment functionality.

Selective deployments Flexibility to selectively deploy. Developers selectively deploy metadata members among SF orgs. “One-click” promotion automatically promotes metadata from successful builds into target release environments and runs Apex test cases.

Rollbacks “Org Compare” reverts a build back to its original metadata with visibility into the difference between source and destination orgs.

Version Control

Automation and Selective Deployment

AutoRABIT … Solving CI challenges on Salesforce


7

Data migration made easy “Data Loader Pro” is an integrated web-based data loader that simplifies promotion of data into Salesforce via a one-step extraction. Developers easily move objects from source to destination sandboxes. Automated data loading eliminates the use of CSV files and manual steps. High volume data loading is further supported through circular reference resolution.

Schedule your data loading Includes a configurable scheduler for automated data loading.

Data Filtering An automated data filtering option that filters at the field level and record type during data migration.

Migrate multiple objects Support for multiple object data loading, preserving complex parent-child relationships.

Synchronize SF orgs Resolves out of sync environments within Salesforce using the ‘Sync SF Orgs’ feature. Source sandboxes are synced with target sandboxes through an easy to use editor eliminating frequent refreshes. “Hotfixes” made in the production environment can be synchronized into downstream developer sandboxes reducing the need for frequent refreshing.

Compare orgs Developers need to compare metadata members among sandboxes. AutoRABIT compares and maintains sandbox data in the source sandbox while deleting records in the target sandbox. Records deleted from target sandboxes are displayed, allowing users to selectively deselect records. Salesforce developers benefit with increased flexibility and control.

Data Loader

Sandbox Management

Automate tests and generate detailed test reports AutoRABIT’s “Test Automation Factory” (TAF) supports automated mobile and multi-browser testing with all leading test automation tools, including QTP, Selenium and JMeter. Testing is automated on multiple sandboxes with multiple data sets. Built-in adapters and wrappers allow developers to generate detailed test reports. TAF also automates the creation of a ticket for every test case that has failed and logging of the same.

Control test execution TAF allows developers to selectively control and execute Apex test scripts / case / scenarios.

Visibility you can trust User friendly, GUI based reporting across all CI processes with configurable CI pipeline and adoption reports. Includes project level dashboards for transparency into requirements, blockers, automation results and testing (functional, user acceptance and regression) on multiple sandboxes with multiple data sets.

Generate detailed code coverage reports Salesforce requires 75% code coverage to deploy code. AutoRABIT is the only vendor that generates detailed Apex Code Coverage reports with detailed information on warnings and failures.

Test Automation

Dashboard Reporting

AutoRABIT is the only cloud based, continuous delivery solution designed specifically for Salesforce. The fundamentals of AutoRABIT is to make the release process simple and easy with the “click of a button” processes along with efficiency and effectiveness with gover-nance and reporting. AutoRABIT is the only cloud based CI server that executes CI/CD best practices and integrates with over 70 leading software development tools. Offered as a subscription model, AutoRABIT installs out-of-the-box and with lower total cost of ownership over unsupported, patch worked open source CI solutions. AutoRABIT is focused on understanding your challenges and goals in order to develop a strong implementation plan to achieve those goals. We have the technical expertise with our customer success team to achieve best practices with these concepts through a maturity model in a phased approach to ensure success. Our motto is that “We are not successful unless your successful in achieving your goals”


8

Why AutoRABIT

Whitepaper CI solutions vs - AutoRABIT · CI solutions ... has no release or change management...

Documents

Transcript of Whitepaper CI solutions vs - AutoRABIT · CI solutions ... has no release or change management...