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

Salesforce SVN Tag

So, you have been developing software for as long as you can remember?

You are on a big project with many developers working across different time zones. Code is getting overwritten, changes are not being tracked, project is running over budget and overtime, and all hell is breaking loose around you. You think that you have a great filing system for keeping track of changes and code updates…until a major catastrophe hits. What do you do? Good thing that you asked. Let us introduce you to the concept of version control.

  • What is version control?

Version control is a software system that captures a version or a snapshot of code or a file system at a certain point of time. This means that you can revert a file or an entire project to a specific previous state. You can also compare changes over a period of time, view who made what kind of modifications and when. Two well-known version control tools include Subversion (SVN) and GIT.

  • I have heard so much about GIT but what is it?

GIT is an efficient, open source distributed version control system that stores codes, files and directories. GIT stores a history of your project in a commit object using large binary objects. ‘Distributed’ here implies that many software developers can work on a given project without the need to share a common network. In essence, when a developer checks out the current version of work, he/she gets a copy of the entire repository.

  • I already use Subversion (SVN). Why should I consider GIT?
  • Work offline:GIT allows you to work on your computer without the need to connect to your company’s servers.
  • Never lose data again:In GIT, every developer working on a project has a complete copy of the code, changes and modifications on his/her machine, including the project’s entire change history. Thus, if something unexpected happens, you have the data stored in multiple locations!
  • Undo any mistakes:GIT allows you to undo almost everything. Being able to undo codes, files and modifications gives your team the courage to try out creative ideas and concepts, without the fear of embracing risks, which, in turn, fosters a culture of innovation.
  • Is Version control really for me? Yes…if you satisfy one of the following:
  • You work in highly regulated industries, such as banking, healthcare, and legal, and you require version control for regulatory reasons.
  • You want a copy of your organizational settings, so that you can revert to older versions, if necessary, or populate a new org with the same settings.
  • You have many developers and features; version control then becomes important to ensure that people do not overwrite each other’s changes.

I trust that this has been an enlightening read for you and that I have been able to answer some of your most fundamental questions about version control. In the forthcoming post on this topic, I will share more specifically about AutoRABIT’s version control management system. Stay tuned and watch out for it.

AutoRABIT for Powerful Salesforce Continuous Integration

Summary

Continuous Integration and Continuous Delivery of applications are essential for higher release velocity and faster go-to-market. With development teams working on multiple parallel releases and multiple Salesforce environments, Version Control is essential for the development teams to maintain isolation, parallelism and change analysis in their development and release process.

AutoRABIT has some very powerful capabilities that can help Salesforce development teams get onboard and streamline their development process with Version Control System. It also has some unique CI capabilities that can keep your deployment footprints lean and also have automated test execution, code coverage, static code analysis enabled as part of CI deployments.

This article talks about the Salesforce Development Environment challenges and why AutoRABIT is the best with its powerful framework for achieving Salesforce Continuous Integration.

Salesforce Development Environment

Salesforce developers can work on individual development sandboxes or share a common development sandbox based on the Salesforce licenses purchased by their enterprise. Developers make configuration and code changes to the key standard objects such as Account, Opportunity, as well as to custom objects as part of their development effort in multiple sandboxes. The security settings on various application components are maintained through a set of profiles in Salesforce.

The release process constitutes migration of changes across multiple release environments, viz., QA/SIT, UAT, Pre-Production and Production. There are some steps to be performed before and after migration of metadata in Salesforce.

After every production release, it is a practice by Salesforce teams to refresh their Sandbox environments to keep their developer and release environments in sync with production.

Challenges in Development

    • Multiple Development Tracks: There are several project teams, viz., Sales, Service, Marketing, etc., working with deliverables for minor and major releases. Consolidating all these changes from multiple development teams without stepping on each other’s shoes is a challenge, as metadata, such as profiles and permission sets, are shared for various development tracks.
    • Multiple Releases: There are minor releases (config only), major releases (quarterly once) and hotfix releases for any business critical issues that happen simultaneously. Ensuring the development and release environments are in sync constantly across these releases is a challenge.
    • Multiple Environments: There are quite a few environments such as SIT, UAT, Performance, Training, Innovation, etc. Maintenance of these environments is a challenge, especially with many pre-refresh and post-refresh activities that need to be done manually after every production release.
    • Complex Salesforce Orgs and Heavy Deployments: Salesforce environments are large and complex with large custom objects, profiles and permission sets, and typical deployments contain few thousands of members.

     

    • Governance and Audit for Deployments: Several types of releases happen in parallel and changes are directly made in release environments such as SIT, UAT, which make it difficult to track the changes from a governance and audit perspective.

     

    • Environments Out-of-Sync and Challenges with Refresh: Since changes happen directly on Salesforce environments during releases and some of the BRs may not go-live to production, being rejected in the UAT phase, the developer sandboxes, release environments and production orgs are out-of-sync. Frequent refresh causes developers to lose their work-in-progress as well as induces a lot of manual steps for the development teams.

     

    • Lack of Version Control: Since multiple development tracks happen in parallel, changes to shared metadata members such as Custom Objects and Profiles happen, resulting in overwriting of code. It is not possible to maintain versions of changes, track them and roll them back in the Salesforce environment.

     

    • Manual Steps in Migration: There are many pre-migration and post-migration steps involved in deployments in addition to large deployment footprint.

     

    • 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, SSO configurations, etc. There is no way to skip parts of metadata in current deployment process without heavy manual intervention.

The Benefits of Version Control System (VCS)

    • Team Collaboration: Developers can check-in their changes to Version Control System and can share it with other members of the team so that they can constantly keep their environments in sync and also be able to perform code-review process on the changes with mechanism such as “Pull Requests”.
    • Change Analysis: Version Control System gives the ability to track various versions of the changes made to a file. It ensures the team is always able to look at application as a series of changes and in case of any bad fix, they can track, isolate and revert the changes done to the metadata.
    • Streamlined Release Management: With multiple releases happening in parallel, the application needs multiple levels of isolation to support development phase, release activities and maintenance mode in case of any hot fixes to be delivered. With efficient branching and merging techniques available with Version Control, it would be seamless to maintain multiple versions of the software efficiently and support parallel development.

Salesforce Metadata Structure

Salesforce metadata can be retrieved from Salesforce into local filesystem as well as deployed into Salesforce with its Metadata API. The metadata of the Standard as well as a custom objects are in XML file format.

Typical Salesforce Object Metadata Structure is given below:

  CustomObject-Salesforce-AutoRABIT 

Note: As you can see a Custom Object Metadata definition, along with all the child metadata, such as Custom Fields, Validation Rules, Sharing Model, is all stored in the same flat XML file in Salesforce.

Salesforce Metadata Constraints Force.com IDE for Version Control

Traditionally, even though developer works on his sub-metadata type like a custom field, when they request Salesforce from any tool, such as Eclipse, the entire Custom Object will be retrieved from Salesforce. Hence, when the developer pushes the changes to Version Control, the entire Custom Object is available for the check-in. This Custom Object can contain the changes done by other developers on this object metadata, which may or may not be eligible for check-in to Version Control System such as SVN/GIT.

It will put additional challenge on the developer to review all the metadata XML files for changes and edit them from his workspace, before he can send the changes to Version Control System.

Here are the metadata components whose children are also metadata, but are embedded in the same XML file as the parent metadata.

Parent Metadata Child Metadata
AssignmentRules AssignmentRule
AutoResponseRules AutoResponseRule
EscalationRules EscalationRule
CustomLabels CustomLabel
CustomObject CustomField

BusinessProcess

CompactLayout

RecordType

WebLink

ValidationRule

SharingReason

ListView

FieldSet

MatchingRules MatchingRule
ManagedTopics ManagedTopic
SharingRules SharingOwnerRule

SharingCriteriaRule

Workflow WorkflowFieldUpdate

WorkflowTask

WorkflowAlert

WorkflowSend

WorkflowOutboundMessage

WorkflowRule

Benefits of AutoRABIT EZ-Check-ins

    • Check-in Only My Changes: With AutoRABIT EZ-check-ins, developer can retrieve the changes up to the last child metadata type (such as changes to custom fields, validation rules, etc.) that he/she has worked on and submit the changes to VCS instead of pushing the entire object.
    • Append Vs Overwrite: AutoRABIT will logically append the modified metadata based on the change done to the file system in VCS, ahead of traditional overwriting of the entire XML file from Salesforce sandbox.

    This can ensure metadata components, such as Login IP Ranges, etc., from developer sandbox will not overwrite what is in VCS.

    • Dependencies: AutoRABIT EZ-check-ins shows cases of all the dependencies to be checked-in for a particular change.

    For e.g., creating a new custom field will have impact on Profiles, Layouts, etc., and AutoRABIT will list all these members to be checked-in, along with their timestamps.

    • No Additional Tools/Training: With AutoRABIT EZ-check-ins, there is no need for training on Version Control Systems, no need for additional tools such as GIT/SV/TFS clients and understanding of complex CLI of these tools to perform the check-ins to VCS, as check-ins can be done from right inside AutoRABIT in your browser. Hence, it is easy to on-board Version Control and CI journey easily with AutoRABIT.
    • Tag the Changes to User Story/BR: With EZ-check-ins feature, developer can associate his metadata changes to the BR or user story in his ALM.

    Checkin-GIT-TFS-SVN-Perforce-to-Salesforce

Challenges with Traditional CI for Salesforce

    • Maintenance of the Build Scripts
      • The packaging and deployment scripts are to be written using ANT Migration Tool and it needs to be maintained for each new Salesforce release to update/remove the metadata types added/changed in the Salesforce release.
      • The scripts are also not robust and flexible, where we cannot retrieve changes based on a “modified date” or by a particular developer.
      • If the changes are to be retrieved from VCS such as GIT/SVN, it would mean that additional knowledge of the CLIs of version control tools are required to maintain the scripts maintained.
      • Using the scripts, we can deploy the entire changes of a GIT/SVN/TFS/Perforce branch into Salesforce but cannot deploy “Cherry Picked Commits” or changes from a particular baseline revision instead of the entire branch.
      • Maintenance of Destructive Changes and Wild Cards in scripts are additional overheads.

     

    • Large Metadata Deployments: The file size of Metadata components such as Custom Objects, Profiles can be really large.

    For instance, even though only one Custom Field is modified in a particular release and is checked-in into VCS such as GIT, the check-in will be made into the Custom Object file. Hence, as part of the deployment, the CI job will deploy the entire Custom Object file.

    This can cause large metadata deployment footprint when deploying from version control system with CI Jobs.

    For most enterprises, the count of Salesforce metadata will be more than 10,000 members and it can always end up in governor limit issues at the time of deployments.

    More details can be found here: https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_metadata.htm

    • Maintenance of Package XML: Preparing Package XML file dynamically to list only the members of particular release in the branch is cumbersome.

 

Benefits of AutoRABIT Salesforce Continuous Integration

  • Delta-Based Continuous Integration: AutoRABIT can deploy child metadata components, which are only “modified” in the release and not in the entire Object Definitions.

This can minimize the deployment footprint significantly and make the deployments lean.

  • Flexible CI Job Configuration: With AutoRABIT, you can have CI Jobs that can perform the following:
    • Deployments Salesforce Org–to–Org from a start date
    • Deployments from VCS (GIT or SVN or TFS or Perforce) to Salesforce sandbox
      • Deploy the entire branch into Salesforce sandbox
      • Deploy from a particular revision from VCS into sandbox
      • Deploy a particular revision into sandbox
      • Deploy a particular BR/user story directly from Version Control System
    • Deployment support for Unmanaged, Managed and Unpackaged Mode in Salesforce.

Salesforce -Perforce-AutoRABIT-CI-Job-Definition

AutoRABIT Unique CI Capabilities for Salesforce

  • Validate Only: Development team can constantly validate deployment of their changes against their release environments so that any possible dependency issues in migration are detected early, reducing the time taken for deployments in SIT/UAT/Pre-Production environments due to dependency issues.
  • Automated Apex Test Execution and Code Coverage Reports
  • Smart Test Execution: AutoRABIT has the capability to retrieve tests that are committed to VCS in a particular release, run the test classes and give code coverage for the release, providing early warning of lesser code coverage.
  • Integrated Data Loading Step: With the integrated Data Loader in AutoRABIT, you can set up Data Loader jobs and add them to your CI Job, so that the entire environment with metadata and data can be set up in one attempt.
  • Static Code Analysis: AutoRABIT has static code analysis component integrated into it that can review the Apex Code against the best practices and provide violation reports, along with priorities.

We are pleased to announce AutoRABIT 3.9 GA, the first GA release after Dreamforce’15, wrapping up most of the awesome feedback received during the event. Here is an update on the new features that will be made available for our customers over the weekend release scheduled for 17th Jan, 2016:

1. Salesforce Metadata Deployments:

a.Back-up and Rollback – You can now take a back-up of the destination metadata before deploying. The deployment can also be rolled-back in case of any functional issues.
b.Smart Profile Deployments – You can now deploy profiles with an option to Skip Visibility settings for the metadata members that are missing in the destination.
c.Metadata API Support for the Winter’16 release components .

2. Salesforce Data Migration Enhancements:

a.AutoRABIT Advanced Data Loader Pro has become more powerful with its comprehensive circular reference resolution algorithm. The Sandbox environment set up can be a breeze now with the records of an object along with the parent-child relationships transferred all at a time.
b.Filters on Record Types are provided to give more flexibility in restricting what records can be transferred to the destination.
c.Incremental Migration to ensure that you can synchronize your environments by migrating the delta of records on a schedule.
d.Chatter Data Migration support.

3.Version Control

a.Thin Client for TFS – Salesforce Teams can now check-in to Team Foundation Server, Register Repositories , Create Branches in addition to deployments right from AutoRABIT .
b.Thin Client for Perforce – Salesforce Teams can now check-in to Perforce, Register Repositories , Create Branches in addition to deployments right from AutoRABIT .

4.ALM Integration – “ No Deployment” Theme supported for Jira

a.Automated deployments can now be scheduled into multiple environments based on the Jira User Story Status with AutoRABIT
b.Attach the metadata changes to Jira tickets for User Story-based deployments .

5.Test Automation Factory

a.Special Automation Templates to automate manual steps with Orchestra CMS deployments, Apptus and Skuid

6.Administration Enhancements
a.Org Level ACL’s – Org Administrators can now set access control levels for various operations in AutoRABIT at the Salesforce Org level for team members .
b.User Profiles – Users logged into AutoRABIT can now map their Salesforce Org user and their SCM user details making it easier for Administrators in Salesforce Org Mapping step.

Please write to sales@autorabit.com for more information and detailed discussion on the Release features.

AutoRABIT has its 3.6 release on Thanksgiving weekend with an aim to bring more joy and happiness to Salesforce Release Management teams across the globe.
Here are brief release highlights .

1. Enriching Salesforce Continuous Integration

In addition to being the only tool that supports all the major version control systems including Subversion , GIT, Perforce and TFS – AutoRABIT also has increased the support for version control deployments in AutoRABIT 3.6 .

  • Deploying a particular revision in version control system
  • User based Auto-commits

Deployment Using Version Control Revision Number

You can now deploy Salesforce objects, based on your version control revision number. During a deployment, give a revision number of the GIT repository, and you can deploy the metadata members belonging to a particular revision number. This is especially helpful during deployment of hot fixes.

User Based Auto-Commits

With AutoRABIT , the development team can continue working with sandboxes, while AutoRABIT runs the entire version control operation in the background with User Based Auto Commits.

Here are the steps to achieve the same:

Step 1: Mapping Salesforce Orgs with Version Control System

Map your Salesforce orgs with a source control system.

Step 2: User Mapping

After version control mappings, the users need to be mapped. With user mapping, metadata would be committed to a version control system. Map Salesforce Org user and AutoRABIT users.

Once a build is triggered, all the changes are fetched from the Salesforce org and based on user mapping, a particular user’s changes will commit to their version control system, as shown below:

2. Salesforce Deployment Enhancements

Validate Your Salesforce Deployments

With Validate Deployment, you can check if your Salesforce metadata deployment would be completed successfully.

After you select metadata types for deployment, click Validate Deployment. Now you can see all the metadata members of Source and Destination Orgs. It shows the metadata members that can cause a deployment to fail, and the corresponding error.
Now you have an option to deselect the error-prone metadata members and ensure that you have predictable deployments.

Enhanced Full profile Deployment

For Full Profile Deployments, AutoRABIT can optionally, remove any components that do not have visibility settings in the destination Org, which can otherwise cause your profile deployments to fail.

Pre-Loaded Salesforce Test Automation Templates for Orchestra CMS and Service Max

If you are using Orchestra CMS for your website publishing or Service Max for field service tracking , AutoRABIT has some great stuff in this release with pre-loaded Test Automation Templates, with which you can get rid of a lot of manual steps that are part of the implementation with those managed packages.

No Eclipse, No Force.com IDE Plug-ins and no complex GIT clients – its all too easy for Salesforce Administrators and Development Teams to check-in their code into GIT repository using AutoRABIT.

With the Salesforce GIT Integration feature in AutoRABIT Salesforce development teams have been able to do the following till now:

  1. Set up GIT repositories in AutoRABIT hosted in GIT Lab, GITHub, Bit Bucket or Internal GIT servers as well.
  2. Create GIT branches for their UAT, Staging or Hotfix environments.
  3. Create deployment jobs that fetch changes from the GIT branches and deploy them into Salesforce Sand Box achieving Salesforce Continuous Integration with GIT.

As part of Salesforce Release Management consulting and Salesforce Continuous Integration Audits that we do with our clients, one of the key challenge that is observed with several Salesforce development teams trying to adopt to version control [ GIT / SVN / Perforce / TFS etc., ] has been the complexity of tooling to commit the changes. This is especially more so felt with administrators who are used to work in their Sandboxes for their configuration changes but suddenly find themselves in a hell lot of tools – to send the changes to source control.

But at AutoRABIT, we thrive on Salesforce community and do these little BIG things that can make salesforce development and release process smoother with lesser pain than before.

With the “EZ-commits”  feature in AutoRABIT – you can now login to AutoRABIT – choose your Sandbox and AutoRABIT will show you the list of changes that are in the Sandbox but not in your GIT branch , as shown below.

You can now select some or all of the changes the changes that need to be committed to GIT, provide a valid GIT comment and check-in the changes .

Please write to support@autorabit.com for any additional information or to Sales@autorabit.com if you wish to play around with this feature.

You can also register for your license with AutoRABIT to get access to all the major features in AutoRABIT that can make your Salesforce Release Management process a breeze.

We also have special offers for DreamForce’15 with licensing and feel free to reach out to us to experience streamlined Salesforce Release Management with AutoRABIT.