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
+88 (0) 101 0000 000
Follow Us

Salesforce GIT Tag

A common need that teams developing on the Salesforce platform express is the desire for a single solution that will take their developers through the entire lifecycle. To make this easier, Salesforce rolled out Salesforce DX, which provides organizations with integrated tooling designed for end-to-end life cycle management.

Salesforce DX is a revolutionary platform that enables modern development practices with the following three key features:

  1. Scratch Orgs – Lightweight source-driven development environments that can be created with ease where changes can be validated, tested and integrated into the mainline quickly with CI platforms such as AutoRABIT.
  2. Unlocked Packages – Customers and partners have seamless distribution and delivery of apps with unlocked packages; this is a paradigm shift towards upgrades rather than battling with metadata deployment failures.
  3. CLI – Salesforce DX comes with an integrated CLI with support for scratch org creation, metadata conversion and migration, as well as data migration.

The real success that Salesforce DX can drive goes beyond CLI and scratch orgs. A team will be successful with Salesforce DX if they are able to seamlessly implement the three key features outlined above. To fully leverage the power of Salesforce DX, they need the ability to restructure their complex metadata into apps so they can manage shared metadata and dependencies. That may sound obvious, but it’s often overlooked. Teams must also be able to set up a unified development and delivery process driven from ALM systems such as JIRA. Finally, they need to be in line with continuous delivery guidelines so that any complete user story can effortlessly go through the deployment chain to production.

AutoRABIT is an end-to-end CI platform designed specifically for Salesforce. It empowers Salesforce teams to be successful with DX with several out-of-the-box features that Salesforce users have long desired. 

The first feature is modularization. Salesforce architects can now restructure and componentize their source code into applications with the modularization feature in AutoRABIT for Salesforce DX. Modularization offers a few key capabilities which play critical roles in long-term success. The first – and maybe the most important – is the ability to fetch and select metadata from DevHubs that form your application. This includes dependent metadata and the ability to create automated test data sets based on the objects selected in the module along with parent/child relationships. In addition, developers can validate a module for successful deployment, publish the module as an unlocked package, and add dependent unlocked package information and automatically include them in deployments. FInally, they can also push the source code in SFDX-compatible format into GIT along with sample data set and JSON configuration files.

A second important feature is Scratch Org Management, which allows Salesforce development teams to create contextual scratch orgs that add more power to conventional Salesforce scratch orgs. The Scratch Org Management feature in AutoRABIT for Salesforce DX has two key capabilities that drive organizational success – DevHub management and user story management.

  • DevHub management allows users to register and maintain DevHubs in AutoRABIT as well as create, maintain and delete Scratch orgs directly from AutoRABIT. They can also create contextual scratch orgs that let them set their own features and preferences, load the unlocked packages of base apps at the time of creation, and load intelligent sample data sets into scratch orgs.
  • User story management ensures holistic Application Lifecycle Management (ALM), as developers can rely on AutoRABIT to connect the dots by creating a user story in ALM, a Scratch Org in Salesforce, or a feature branch in GIT. AutoRABIT lets users assign and create a Scratch Org for a user story in any ALM (Jira/VersionOne/TFS) or in GIT for a user story and check validations, review and approve details of commits and make sure that all relevant user story information is updated back to the ALM.

Continuous delivery is critical for organizations that need the capability to promote a completed requirement anytime from development to production — and ensure quality and compliance parameters are met. With AutoRABIT for Salesforce DX, a developer can create a scratch org with all the required metadata and data pre-requisites. They can also validate the changes done in scratch orgs, complete the review and approval process for changes, push approved changes to a GIT branch, and raise a pull request. Release Manager allows users to merge the approved user stories into a release line and validate them, and automated functional tests can be run post-deployment for further quality assurance. More importantly, the user story will be ready for production deployment.

A comprehensive CI Server with a check in-merge-deploy framework and full support for SFDX ensures that Salesforce development teams experience continuous delivery for their applications. And for organizations that rely on Salesforce to drive their market success — there’s nothing more important than that.

To learn more, check out our video on Experiencing 360-Degrees with Salesforce DX

Niranjan Gattupalli, is Senior Director of Enterprise Services at AutoRABIT. Follow him on Twitter at @tweet_niranjan

DreamForce 2016 has 900+ Salesforce Customers, Architects, MVPs spending their valuable time on Salesforce release management at AutoRABIT Booth in Devzone and it was some experience !!!.
We could divide the Salesforce fraternity that visited us at the booth into three segments :

  1. Clients who were not sure where to start the whole thing and the amount of knowledge and expertise required to make the journey successful
  2. Clients who have used some tools but did not reach the level of automation or scalability to the extent they anticipated
  3. Few Architects and experts, who were able to assess the current state of Salesforce Continuous Integration and were able to visualize a wishlist for future.

With a much bigger and awe-inspiring DreamForce’16 making its way in few weeks, it was very important to assess AutoRABIT in three segments and to ensure we have a release that announces itself in such a way that answers most of the challenges from the Salesforce World with respect to CI and release management.

The result is the much awaited AutoRABIT 4.0. Considering it is a pre-cursor to DreamForce and we know the hype and expectations around it , this has been one of the biggest release ever from AutoRABIT.
The first of the AutoRABIT 4.0 blog series is to outline the thought process and the problem areas that went into the brainstorming of the release.

The unexplored territories in Salesforce Continuous Integration

  1. 360 Degrees view for Salesforce Continuous Integration – Salesforce CI is not just about deploying some changes from a GIT branch into Salesforce Sandbox using tools like Jenkins. It needs lot more support from tooling to achieve 360 degrees Salesforce CI for Check-in, Merge , Deploy seamlessly.

The following are some of the items that need to be looked at on how the current tooling is letting down the                vision of a Salesforce CI practitioner in achieving higher maturity in the company with release automation.

  1. Developers should be able to check-in their changes into a Dev Branch effortlessly without crypticness associated with a version control system.
    • Check-in mean that Developers take the entire metadata file  [ a profile or a custom object] from their Dev Sandbox using Mavensmate or Eclipse, overwrite the file into a GIT clone and push it into a common GIT Dev Branch.
    • Most developers miss out on the fact that they must check-in Layouts, Profiles etc., when they a create a custom field and just what they worked on and there is no way to detect any of these missing dependencies apart from a bug identified by QA members
    • Does any of the CI tools understand the salesforce parent-child metadata concept or the problems with Profiles or Custom Labels being the largest shared files which keeps getting modified for other changes.
    • Pushing the check-in information into ALM so that user story and metadata are associated for easy reviews and sign-offs is another challenge and release managers even today maintain large excel sheets “asking” for what the developers worked on to be maintained in a separate sheet.
  2. Release team should be able to easily cherry-pick / merge what goes into the release as all user stories may not make the cut.
    • Merge is not just about integrating two branches. There needs to a branching strategy behind it.The decision of feature branches Vs common Dev branch for the entire team needs to be discussed at depth.
    • GIT tooling support is that not great when it comes to merging a set of changes  [ group cherry-picking ] easily from a branch into another branch. It becomes a hard task for the release team to be able to cherry-pick a group of commits for completed user stories and merge them into a higher release branch.
      • GitHub, BitBucket doesn’t support cherry picking in cloud – need to install a client tool like GitHub for Windows or SourceTree or TortoiseGIT.
      • SourceTree doesn’t support grouped cherry-picking – TortoiseGIT supports it.
      • Conflict resolution – the less we talk about it, the better if I am Salesforce adminstrator.
        • The editors like SourceTree doesn’t support merge changes from both source and destination. Its either local or remote incase of a conflict block.
      • Tagging a group of commits to a release and deploying them is looked as too far dream with the tooling around.
  3. Deployment – Deployment of changes from version control to Salesforce Sandbox is not just about using an ANT script and calling a Jenkins Job. It is about lot more things in Salesforce Deployment.
    • Deploying an entire branch from GIT will inevitably result in “Too Many Files” issue due to Metadata Governor limits .
    • How this often ends up is that Salesforce teams stop committing the profiles, custom objects etc., to GIT and end up with code items which is not the right spirit of version control.
    • There should be a support for deployment from a particular baseline revision or able to deploy a hotfix commit directly from version control.
  4. Support for not just GIT – Several large enterprises use SVN, TFS , Perforce and the Salesforce CI is not just about GIT.

With AutoRABIT 4.0 , we are proud to announce 360 degrees support Salesforce Continuous Integration with its check-in editor, Merge Editor and rich deployment support.

2. Profiles, Profiles and Profiles

There has been a lot of talk and experimentation being done around managing the profiles. Administrators have tough time deploying the profiles, Governance teams have tough validating profiles and Architecture team to set rules for what should be excluded in Profile Migration and ensure they are met by the development teams.

The fact remains that Managing Profiles has been a primary challenge for Salesforce teams across the globe.

With AutoRABIT 4.0 , we are pleased to announce a Profile Designer to check-in, Compare and Deploy the profiles across multiple sandboxes that gives you full control over the Profile Management.

3. Manual Steps in Salesforce Metadata Migration

Inspite of ANT which is at best a handy tool for for migration or changesets, it is still a case of heavy manual operations post migration.
It could be items related to updating email addresses , creating groups, updating scheduled jobs or it could be items arising out of using unsupported metadata  in migration.
AutoRABIT 4.0 is the first ever tool to introduce a framework for automating pre/post migration steps in Salesforce migrations.

4. Salesforce Release Management is not just about Metadata

While Salesforce CI is often circled around metadata migration , which is only addresses a part of the challenge faced by Salesforce administrators. Setting up environments with the data of the important objects with least effort is often left as manual exercise or needs to have another set of tools doing the job.

While it is known that AutoRABIT has a rich integrated Data loader , it has just become even better with 4.0

5. Test Automation

AutoRABIT 4.0 has enhanced its Test Automation Factory model to revolutionize test automation with enhanced support lightning and Salesforce appexchange components.

6. CI Adoption and ROI justification

While Management teams invest in huge time and money for innovation and automation, a big challenge for them is to able to monitor, measure and visualize the adoption rate of automation and the ROI benefits associate with it.

AutoRABIT 4.0 has a reporting module that gives a holistic view of metadata deployments, data migration, CI results, test results etc., giving complete picture of CI adoption and ROI reports.

If you think these are the challenges that you are looking to address in your company in pursuit of Salesforce release automation, scheduled a discussion with us at , with your problem statement and we are happy to assist.

I will follow-up this blog with a detailed feature walk-through of AutoRABIT 4.0 .

Branches are independent lines of work that stem from a single central code base. Today, most Version Control Systems (VCS) support branches. Depending on your VCS, the main branch may be referred to as master, default, mainline, or trunk. Developers can create their own branches from the main code line and work independently along with it.

Why is Branching Important?

Branching enables teams of developers to easily connect with one another inside a single central code base. When a developer creates a branch, the VCS creates a copy of the code base at that point in time. Developers can easily integrate changes from other developers to sync up with features and ensure their private branch doesn’t stray too far from the master.  Any changes a developer makes to the branch will not have an impact on the work of other developers on the team. This is a blessing because the features under development can create volatility, which can impact all the work if it were happening on the main code line.

Three Branching Strategies for Agile Teams

Branching models often differ between teams and are an issue of much debate in the software world. A major point of contention is what amount of work should remain in a branch before it gets merged back into the master.

1.Release Branching

It refers to the idea that a release is contained entirely within a branch. This means that later in the development cycle, the release manager will create a branch from the master (for instance, 1.1 development branch). All changes for the 1.1 release have to be applied twice: first to the 1.1 branch and later to the master code line. Working with two branches is additional work for the team and it may, sometimes, overlook merging to both branches. Release branches can be cumbersome and difficult to manage as multiple people work on the same branch. If you have to do a release branch, then ensure that you create the branch as close to the actual release as possible. Release branching is an important part of supporting versioned software in the market. A single product may have multiple release branches (e.g., 1.1, 1.5, 2.0) to support sustained development. Changes in previous versions (i.e., 1.1) may have to be merged with later release branches (i.e., 1.5, 2.0).


2.Feature Branching

 Looking for a more flexible branching model, many agile teams have migrated from release branching to feature branching. A feature branch model keeps all the changes for a particular feature intact inside a branch. After the automated tests fully test and validate the feature, the branch is then merged into the master.

Feature branches are often integrated with feature flags, which enable or disable a feature within the product. That makes deploying code into the master a cakewalk and enables controlling of a feature when it is activated, making it easy to initially deploy the code, well before the feature is showcased to end-users. Feature flags also ensure that the code, while in development, can remain inactive within the build. If something goes wrong when the feature is enabled, a system admin can turn back the feature flag and get back to a former good state, rather than having to deploy a new build.


3. Task Branching

Every organization has a natural way to break down larger work into individual tasks inside an issue tracker, such as JIRA software. Issues then become the team’s central point of contact for that piece of work. Task branching is also known as issue branching, and it directly connects those issues with the source code. Each issue is implemented on its own branch, with the inclusion of the issue key in the branch name. It’s easy to identify a particular issue a code implements: you just have to scout for the issue key in the branch name. With such level of transparency, it’s easier to apply focused changes to the master or any longer lasting legacy release branch.

Since agile pivots around user stories, task branches sync up well with agile development. Each user story (bug fix) lives within its own branch, making it easy to view the issues in progress and those that are ready for release.

As you create future releases, it is a good idea to try to migrate older customers onto newer branches to reduce the potential number of branches you might have to patch up to fix a bug issue.

Using this technique, you can deploy solutions using your technology to a range of customers who require different levels of service. You can also segregate your current deployments from dangerous new code in the trunk, with the worst merge scenario being a single branch.


 How AutoRABIT Can Help You with Version Control

 AutoRABIT has some very powerful capabilities that can help Salesforce development teams get onboard and streamline their development process with Version Control System. AutoRABIT can help in setting up a central GIT repository. After creating a central GIT repository, the master branch will be populated with metadata from production. This is done by committing all the metadata folders, along with the Package Manifest file, to master branch and pushing them to remote repository.

AutoRABIT commits the developer’s changes by updating the folders and package file. In other words, the changes will be committed to the developer’s local repository. AutoRABIT also allows you to merge multiple branches and you don’t have to make changes in that particular repository, since any change in AutoRABIT will be reflected in the particular repository branch and vice-versa.

Get AutoRABIT…Your failsafe solution for Version Control implementation.





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.

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 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 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 for any additional information or to 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.

This is a continuation post to the series of posts on the continuous delivery of Salesforce applications . Incase,  if you have missed the first one – please read it here where we discussed about the need for a dedicated CI tool that is sensitive to Salesforce world . In the subsequent posts , we will start discussing the various requirements of Continuous delivery of Salesforce Applications .

Salesforce application development has always had business users part of the development process who prefer working directly with Sandbox / Org rather than using source control for submitting their changes . However, the adoption for source control for Salesforce has always been on the constant rise .

The choice of Version Control System :

Subversion , GIT , TFS etc.,  all have strong source code management capabilities and has been adopted strongly by Salesforce development teams . While most teams still figure out what is the best version control tool for them – there is no direct answer for the same rather a combination of factors that drive the version control system.