CI-solutions-Versus-AutoRABIT

®
Salesforce Release Automation
vs
Whitepaper
AutoRABIT
CI solutions
Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com
Continuous Integration (CI) often means different things to different people.
Let’s start by agreeing on a single deﬁnition 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 changes
Automate build and deployment, eliminate change sets and limit pre/post
manual steps, selectively deploy
Automate testing - test on multiple sandboxes and data sets at scale
Sandbox 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 controls
Solution 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 speciﬁcally for Salesforce. The fundamentals of AutoRABIT
is to make the release process simple and easy with the “click of a button” processes along with efﬁciency 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

CI-solutions-Versus-AutoRABIT

More Related Content

What's hot

Similar to CI-solutions-Versus-AutoRABIT

CI-solutions-Versus-AutoRABIT