®

Salesforce Release Automation

vs

Whitepaper

AutoRABIT

Homegrown CI solutions

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

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, the demand for more functionality also grew. To provide all the functionality and at the rate that they were being requested was neither feasible nor sustainable. Instead, a decision was made to build a platform that gave users the freedom to develop applications with the functionalities that they needed. Enter in Force.com; a cloud-based platform that can host other types of applications. Force.com enables developers to create and deploy applications that can leverage core functionality provided by Salesforce.com, such as Chatter, workflows, business processes, mobile software development kits, communities, and real-time hierarchical reporting.

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, hence, it can be cumbersome to develop on this platform. If you have worked in the Salesforce (SF) environment you might be familiar with the aforementioned challenge and the following listed below:

Manual deployment: The deployment process in Salesforce is still fairly manual. While this situation is slowly improving; many developers who are used to performing automated deployments can get easily frustrated by the numerous activities that they have to manually perform within Salesforce (SF). For instance, after a production release, it is necessary for developers to perform pre-refresh and post-refresh within the SF platform. Typically, the SF platform has multiple environments such as System Integration Testing (SIT) and User Acceptance Testing (UAT) and performing refresh activities can be challenging to accomplish due to the fact that these activities are predominantly manual.

Out-of-Sync Environments: Ensuring that the SF orgs are in sync across environments is a constant challenge for developers. Many factors contribute to out-of-sync SF environments. For instance, during major and minor releases, multiple developers work to produce project deliverables or metadata on a tight schedule. In order to meet deadlines, accommodate new requirements or to correct an error developers will typically perform hotfixes within in production environment. Other times, business users may place a hold on features that go-live into production. The impact of these factors is the falling out of sync of developer sandboxes, release environments and production orgs.

Migration within Salesforce Orgs: Salesforce environments are known for being large and complex. Typical deployments contain few thousands of members, including large custom objects, profiles and permission sets. Therefore, attempting to manually manage pre-migration and post-migration steps in deployments can be an uphill battle without the right data loader and deployment solution.

Code overwrite: SF does not provide developers with the capability to maintain versions of changes, track them and roll them back in the Salesforce environment. With multiple development tracks and numerous changes being made to shared metadata members such as Custom Objects and Profiles, code overwrite is often the sad reality of many SF development teams.

Maintaining Governance and Audit standards: It is not uncommon to have several types of releases happen in parallel within the SF environment. However, when changes are directly made in release environments such as, SIT, UAT, SF does not provide functionality to help track changes. This makes the maintaining governance and audit standards difficult.

Exclusion Lists in Deployment: Security guidelines and architecture recommendations can require certain 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 skip parts of metadata in current deployment process without heavy manual intervention.

Salesforce development

Top challenges with Salesforce development

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

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.

Homegrown solutionsAchieving automated continuous integration and delivery for Salesforce application development is a goal for most developers. To attain this goal, it is not uncommon to find Force.com developers attempt to build their own homegrown solutions by leveraging open source tools. The open source route is popular among developers for many reasons but this paper will argue against the use of homegrown solutions.

First, open source solutions are free to acquire and to use. However, in the final analysis, it is rarely cheaper to build your own solution versus acquiring a vendor-provided solution. For instance, when you purchase a solution from a third-party vendor, they have a team of architects and developers who do nothing but work on the product, do bug fixes, add features and functionalities and in some cases, configure it for your environment. For the vendor, that development cost is spread across their entire customer base, and not wholly transferred to just you. In order for you to make something comparable, you would need to employ teams of architects and developers, but you would not have the customers base across which to spread the cost of development. Your company will have to bear the cost of development, configuration and maintenance alone.

Second, developers can see the source code and understand how it works, thereby lending them a visibility with the open source software that is not available with vendor-provided software. The challenge with this is that there is a lack of development standard and common security infrastructure with open source solutions. As such, if your organization lives within a regulated industry, that requires that the organization actually owns or has access to the application source code (very common with government agencies), this is not a feasible option. Even with companies not within a regulated industry, the need for security cannot be overstated.

Third, with open source, developers are free to modify the software however they like, and to release those modifications and this is not the case with vendor-provided solutions. In essence, a developer is able to run these software packages for any purpose. However, homegrown CI solutions built on open source applications such as Jenkins, are difficult to build, maintain and scale. This is as a result of the multiplicity tools being used for the build. As tooling gets more and more complex, the homegrown end-to-end solutions don't really scale. Additionally, maintenance gets cumbersome and expensive as it requires dedicated human and monetary resources.

The most popular open source tool being used by Salesforce developers to support their continuous delivery and release management is Jenkins. They default to Jenkins because many come from Java development environment and they try to make Jenkins work for Apex development environment. As was established earlier in this paper, Apex comes with very little tooling options. In order to build a solution to support a seamless CI practice using Jenkins can be an uphill battle, especially for the inexperienced developer.

For the purpose of this paper, we will focus our attention on Jenkins, primarily highlighting the ways in which it does not support CI within the Salesforce environment. The paper will also lay out the factors developers, admins and release managers should take into consideration when shopping around for a CI solution for their Salesforce CI and release management needs.

How are developers currently managing these challenges within Salesforce?

will examine both options.

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

4

Jenkins, a continuous integration and delivery application to build and test software continuously is one of the most popular open source CI solutions in the industry. Developers choose Jenkins because it is free, it has a large plug-in library and it can be used across various platforms. However, once developers start to use Jenkins for Salesforce development and deployment, they quickly realize that Jenkins was not built or optimized to facilitate Salesforce continuous integration and delivery and release management.

Jenkins is not specifically designed for Salesforce: Jenkins is an excellent continuous integration tool. However, it is specifically designed to handle Salesforce development and deployments. To make it work as a build tool for Salesforce requires numerous plug-ins, multiple manual steps and configurations. This amounts to unnecessary overhead for the company.

Jenkins does not facilitate code check-in: Checking in code is a major part of the CI process and it remains a major pain point for many SF developers. Within Jenkins, a Salesforce developer checking in code needs to perform about 4-5 steps, many of which might be manual. For instance, a developer typically has to move code from a developer sandbox to eclipse editor, install plugins and refresh from the salesforce box into a file system to get the changes and then move these changes to a version control tool when using Jenkins. Furthermore, while Jenkins has support for retrieving and deploying all changes from standard version control system branches into Salesforce it does not have a check-in editor. The function of a check in editor is to make it easy for teams to frequently check-in their code into a version control system. For example, to check-in the changes into GIT using Jenkins, team members must be extensively trained on all the cryptic essentials of GIT. It can be an odious task to check in a code change within a SF browser into a version control tool when a Salesforce developer elects to use Jenkins for Salesforce development.

Jenkins does not facilitate merge Editor: Salesforce teams who have adopted CI in their Salesforce development process typically cite merge complexities as a major factor that slowed down their adoption. Salesforce administrators who are used to developing their code in browser, merges may appear daunting. If they choose to use Jenkins for the CI practice, they will discover that Jenkins does facilitate merge as a CI best practice.

Jenkins demands a lot of scripting effort: Firstly, Jenkins is not built for Salesforce (SF) deployment. Jenkins will require the developer to write this script and feed it this script so that it can run it. For instance, in order to perform a SF deployment in Jenkins, one has to write a script that will package metadata into a SF deployable format. This script is not generated by Jenkins. This means that developers have to write instructions to help Jenkins understand how to deploy in SF. Furthermore, developers need to write scripts to run tests in Jenkins. This is so because, Jenkins does not understand Apex testing, it understands Junit, .NET unit testing and other open source testing platforms. Next, in order to commit code into a version control tool, Jenkins typically will require a URL to your version control tool in order to pull all your Java and .NET changes. Developers will need to write a script for this too. In essence, the scripting effort to make deployment happen using Jenkins can be overwhelming, excessively manual and time consuming.

How does Jenkins handle Salesforce Continuous integration (CI) and Release Management (RM)?

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

5

SF governor limits. If you are familiar with Salesforce, you have heard of the 10,000 govern limits. The governor limit is Salesforce’s way of ensuring that developers write efficient and scalable code. This element in the Salesforce environment often has developers asking questions such as “How do I separate my members into batches of 10,000?” “How do I check for dependencies and ensure that I deploy in a logical manner?” Then, there are times in a development cycle when developers just want deploy only the changes within a specific release. When you consider Jenkins, ask if you can you accomplish selective deployments in Jenkins? You will find that the answer is no. Rather when you want to deploy, Jenkins attempts to deploy entire branches every time. This is so because Jenkins is not designed to understand your unique release cycles nor does it support selective deployments or selective Apex test execution.

Testing: Jenkins is capable of executing automated test cases and scripts for functional and performance test. However, sometimes, developers might want to execute selective Apex tests. Since Jenkins provides support for only open source testing platforms, a developer, in order to successfully execute automated tests must have in-depth knowledge of programming. Without this knowledge, it’s hard to execute tests within SF. Even if a developer has a desire to learn how, bridging that learning curve adds on significant time to any development schedule.

Data migration: Jenkins does not understand the nature of Salesforce data since it’s mainly a CI server. It only focuses on application deployments and not data or even metadata migration. It does not have an integrated data loader that allows for a seamless process of data migration between orgs and sandboxes. Therefore, data migration can be problematic.

Tracking Governance and Audit for Deployments: Teams using Jenkins encounter many challenges tracking and accounting for changes made by the various members of the development team. Most deployments and builds done by Jenkins are done via a single, common user, making it unfeasible to track deployments. All the traceability is only at the code level provided by the source control tool being used.

Overhead: A reason why people are moving to SF is due to the fact that people no longer want to incur software infrastructural overhead. Yet, to install Jenkins, developers need physical hardware, must install and setup a version control repository and write build/package scripts. All of these amount to huge overhead.

To help provide an answer to this important question is the reason why AutoRABIT has developed an enterprise comparison document to explain how to decide on the best CI and release management tool for you by highlighting the features necessary to implement a successful Salesforce CI practice. Now that we have hopefully succeeded in revealing some of the common pain points that you typically face in your current deployment process, we would like to explain what AutoRABIT is able to bring to your company and Salesforce development process.

A key question you should ask yourself when sourcing for a CI and release management solution is “Does this solution support CI best practices?” To get even more granular, ask if the solution under consideration helps your team to:

1. Maintain a source repository; commit code frequently and track changes. 2. Automate build and deployment. 3. Automate testing; test frequently and thoroughly. 4. Manage sandboxes effectively. 5. Make it easy to identify, compare and synchronize changes across Salesforce organization. 6. Manage data migration across orgs.

The good news is that there is a solution that empowers SF developers to overcome CI and RM challenges and follow CI best practices. That solution is AutoRABIT.

So how does one choose the best solution for Salesforce CI practice and release management?

If you use Jenkins, then you are more than aware of the aforementioned challenges. However, if you are considering Jenkins you are now aware of the possible challenges that you will encounter.

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

6

AutoRABIT is a cloud based continuous delivery and release automation suite specifically designed for Salesforce.com. AutoRABIT helps Salesforce developers, admins, analysts and release managers with out-of-the-box automation of version control, deployment, testing, data loading and sandbox management. With the features of AutoRABIT, your team is able to achieve higher release velocity (days instead of weeks/months) and substantially improve time to market.

Integrate with your version control tool: Right out of the box, AutoRABIT integrates with the leading version control systems on the market. There is no need to adopt a new version control system, simply bring what you have.

Use a check-in editor: AutoRABIT comes with a check in editor. This helps to facilitate the process of checking in code into version control and Salesforce. The check-in editor shows changes, selects the changes developers want and commits to version control.

Auto-commit changes: Our solution allows you to auto-commit changes from each Salesforce developer into Version control; thus effectively eliminating the risk of code overwrite.

Track changes: Interested in knowing who made what changes and when? Our solution offers visibility into every change that happens in the sandbox/SF Org. The Change Analysis component provides details of authors, modified/added/deleted files, line(s) of code modi-fied in each object/file and the detailed reports of each modification, displaying changes from the last build cycle to the current cycle.

Version control adoption is easy: Getting on board with using version control is easy and realistic if teams are using AR. You do not need to spend precious development hours trying to learn GIT commands or a new type of version control system.

CI is a software development practice that enables the rapid and repeated development and deployment of allow high-quality software using minimal manual effort. AutoRABIT models and supports CI best practices and automates the Salesforce release management process.

AutoRABIT provides CI support for: 1. Managed and unmanaged package deployments. 2. Deployments from version control systems to Salesforce. 3. Scheduled builds and deployments. 4. Execution of Apex tests. 5. Visibility of code coverage. 6. Data loading.

Reasons to pick AutoRABIT as your Salesforce continuous delivery and release automation solution.

Version Control

What is AutoRABIT?

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

7

Get support for Quick deploy: SF has a feature that allows developers to deploy components to production by skipping the execution of all Apex tests for components that have been validated within the last four days. This feature is known as Quick Deploy. Since, developers no longer have to wait for all tests to run for deployment to complete in production, deployment will likely finish in less than 30 minutes. A quick deploy is only possible if a developer does not make code level changes. However, once code level changes are made, a developer will have to create a package and validate again and this is known as Validate deploy. While Jenkins does not have support for quick deploy or validate deploy; AutoRABIT supports both.

Cherry-pick deployments: With AutoRABIT, you can cherry pick what you will like to deploy. For example, a developer can select to deploy metadata members from SF org to SF org or from a version control system to SF org. Developers can cut down deployment time using AutoRABIT’s One-click promotion feature to promote metadata of a successful build into various release environments and run apex test cases for sanity check of the promoted build.

Rollback if you please: What if developers find issues with application functionalities after successful deployment? No worries. AutoRABIT has the capability to revert a build back to its original metadata with added visibility difference between the source and destination orgs with “Org Compare”. The option to rollback lends support for times when there might be failure during deployment.

Automate your tests and generate detailed test reports: AutoRABIT’s Test Automation Factory (TAF), supports execution of automated tests on all industry leading test automation tools such as QTP, Selenium, JMeter to name a few. With built-in adapters and wrappers, developers are able to generate detailed test report generation. This feature also automates the creation of a ticket for every test case that has failed and the logging of the same.

Be in control of test execution: AutoRABIT’s TAF, gives developers control of test execution as they are able to selectively execute Apex test scripts/case/scenarios.

Deployment Builds

Test Automation

Generate detailed code coverage report: Salesforce requires a 75% code coverage to deploy code. AutoRABIT has the capability to generate detailed Apex Code Coverage reports. Test Coverage reports within AutoRABIT also furnishes developers with details about warnings and failures generated in the reports. This gives developers a measure of the adequacy of the test that has been conducted for code.

Code Coverage Report

Data migration made easy: AutoRABIT’s Data Loader Pro has many additional features that make it better and easier to use than the traditional data loader. For example, the integrated web-based data loader makes it easy to promote data to Salesforce using a one-step extraction, developers can transfer objects from a source sandbox to destination sandbox.

Schedule your data loading: Developers are busy and AutoRABIT knows this. This is why with our Data Loader Pro., developers can schedule data loader process.

Data Loader

Copyright © 2016 AutoRABITwww.autorabit.com | info@autorabit.com

8

Filter data as you move: Developers can use the filtering option provided, as part of our solution, to filter at the field level and record type level during data migration.

Migrate multiple objects: There is also support for data loading multiple objects based on complex parent-child relationship.

Fix circular references: AutoRABIT has a unique algorithm to resolve Circular References.

Sync up your SF orgs: Many factors lead to sandboxes and orgs falling out of sync within a SF environment. AutoRABIT resolves out of sync environ-ments within Salesforce using the ‘syncsforgs’ feature. This feature synchronizes the records in source sandbox with that of the records in the target sandbox.

Compare orgs: SSandbox management enables developers to compare code between metadata members of two sandboxes. After AutoRABIT has compared data present in the sandboxes, it keeps the corresponding records of those present in the source sandbox and deletes the remaining records from the target sandbox. All the records that will be deleted from target sandbox will be displayed during the operation and users have an option to unselect some of the records if they consider them necessary to be present in the target sandbox. This is a big plus for Salesforce developers who want to compare code between version control and Salesforce orgs.

Get the visibility you can trust: ALM aggregated project dashboard is one of the most powerful and most used features of AutoRABIT. Project Dashboard enables transparency in the team – be it the requirements, the list of blockers logged in, the automated results, or the results of the functional test run from the test case management as uploaded by the QA team. All the results are aggregated in the ALM dashboard, thus making AutoRABIT work like a thorough team system, enabling the team stand-ups to be all the more effective.

ConclusionJenkins only offers bits of the facets that power CI delivery but AR gives you the full breath. So, if you are ready to experience a more

robust release management solution visit us here (www.autorabit.com) or sign up for a free trial here (https://login.autorabit.com).

Sandbox Management

ALM Dashboard