Salesforce Continuous Integration – What is not explained !!

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 Sales@autorabit.com , 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 .

Leave A Comment