Skip to main content
AutoRABIT, Inc.

Create New Job

This section will guide you to create a new Continuous Integration (CI) Job.

Pre-requisites for creating a new CI:

  1. Plug-ins and sandboxes to be registered with AutoRABIT.
  2. You should have a permission to create a project using AutoRABIT.

To create a new CI job:

  1. In AutoRABIT homepage, Click at CI Jobs.
  2. Next, click on Create New Job to open a job creation wizard. The wizard contains four tabs on the left panel:
    • CI Job Details
    • Job Settings
    • ALM & Test Settings
    • Module Settings
CI Job Details

 Provide the following details:

  • Name the CI flow in Job Name field e.g. "CI Demo".
  • Give a short description about job in the Job Description field.
  • Click +Add to add a Functional Module or select from the list of  modules available. (For more information on Functional Modules refer Functional Modules section below)
  • Clicking on Next will lead you to the next section Job Settings.
  • You can also find the entered job name displayed below Module Settings. See the screen shot below.

Functional Modules

AutoRABIT projects can contain 'N' number of functional modules that logically constitute the project being developed. A functional module has test cases attached to it. When you attach a set of relevant test cases to a functional module, and in turn, attach the module to a project, granular test reports gets generated.

In the Functional Modules section, you have an option to either add or delete a module.

  1. Click Add functional module (+Add) to add a module or
  2. Select the required module and click Delete functional module to delete a module.
Job Settings

Job Settings provides the Build-Install-Test configuration settings to deploy and test the metadata changes into a Sandbox from either Version Control System (VCS) or another Sandbox in a scheduled manner as well as on-demand enabling Continuous Integration.

Select the Build, Deploy, Test, Schedule, Code Coverage and Static Analysis.

Note: You can configure only the selected options in the Job Settings page.

 

Build

AutoRABIT works in a scalable server- agent framework. There can be one or more build, deploy, and test agents that can be used to accelerate the packaging, deployment and test automation tasks. There is also a provision of master to add parallelism to the agent framework - where multiple tasks will be distributed across various agents in parallel, driven by the AutoRABIT's server internally.

The master / agent(s) typically are software that runs inside a dedicated / shared private cloud instance. The configuration of master or agents refers to the hostname of the cloud instance that runs the agent.

Build master server details on which a build has to be triggered.

For a build, the metadata can be fetched from two sources:

  1. Salesforce Org- If development team makes their changes directly in Salesforce Orgs without any source control system. In this scenario, the project can be configured optionally for an auto-commit to version control system like GIT, SVN and TFS. The repositories assigned by Admin to a user are only displayed here. This helps to enable version control system being used as a source of continuous back-ups while the usage of version control system is abstracted from the development teams.
  2. Version Control System – This option can be selected, if development team commits their changes into a source control system like GIT, SVN or TFS as a development practice.
1. Salesforce Org

  1. In Salesforce Org(Source), choose the source sandbox to fetch the metadata members from.

  2. Optionally, click View Details to view the complete details of the selected source. The following screen shows the details of a selected source.

  1. In Package Type, select the type of package to be used. 

There are three packaging options available in AutoRABIT  for retreiving and bundling the changes from a source sandbox, namely, Unmanaged, Managed and Unpackaged.

  1. Unmanaged packages

Unmanaged packages are typically used as application templates to provide developers with the basic building blocks for an application. Once the components are installed from an unmanaged package, the components can be edited in the organization they are installed in.

  1.  Managed packages

Managed packages are typically used by Salesforce partners to distribute and sell applications to customers. These packages must be created from a Developer Edition organization. Using the AppExchange and the License Management Application (LMA), developers can sell and manage user-based licenses to the app.

Managed packages are also fully upgradeable. To ensure seamless upgrades, certain destructive changes, like removing objects or fields, can not be performed.

Note: When you select Managed package type, the source and the destination Namespace has to be different.
More information about this can be found at this link :
https://help.salesforce.com/HTViewHelpDoc?id=sharing_apps.htm&language=en_US
  1. Unpackaged Mode

Unpackaged Mode fetches all the metadata members present in the Organization that has got modified from the last AutoRABIT cycle.

 

  1. Additional Settings:

        

  1. Exclude metadata types:
  1. All the changes made to the metadata are displayed.
  2. You can select the metadata types that you want to exclude from an AutoRABIT build deployment.

 

B. Profile Settings

  1. Retain login IP ranges: If you want to login with a particular Salesforce org, you have an option to restrict IP ranges. By selecting Retain login IP ranges, the destination Salesforce org or Version Control System, you can retain the IP ranges.
  2. Retain User Permissions: You can retain the user permissions of the metadata types in the destination org or Version Control System.​​​​​​

  1. Prepare destructive changes

If this option is selected, destructive changes will be generated based on CI job source.

  1. CI job source is sandbox: The current build metadata build snap shot is compared with last successful deployment metadata snapshot. If any metadata members (which exist in last successful deployment metadata snapshot) are missing in current build metadata snapshot those members will be listed as destructive members. For first build no destructive will be prepared.
  2. CI job source is version control: We are listing destructive members based on deleted files in between given start revision and head revision.

 

  1. Exclude baseline managed packages changes 

If a managed package is installed in a Salesforce org on a particular date, but a different date is given on the CI job created, then the installed managed package numbers are also loaded. To skip those installed managed packages, we have an option to exclude baseline managed package changes.

  1. Include Picklist modifications

Whenever a picklist value is modified, or deleted or added, the picklist last modified date is not updated by Salesforce. Irrespective of whether the picklist value has been changed or not , selecting this option will pull all the picklist fields into the given source org. This option is only available only if the source is a Salesforce org.

  1. Auto-commit changes to version control

This allows you to configure your Ez- Commit model for Objects recordType Metadata picklistValues.

  1. Here you have an option to select:
    1. Append
    2. Replace
  2. Now, select the Version Control System, and fill in the details:
    1. For SVN, give Repository URL, User name, and Password.
    2. For GIT, select the Git Repository, Branch and give the User name, and Password.
    3. For TFS, give the Repository URL, Project path,User name, and Password.

  1. Post Build Activities

Additionally, AutoRABIT provides an option to execute post-build activities, like:

  1. Sending an email notification along with files (package.Xml and scmlog.txt file) on the success and failure of a build. If the build is of Version Control then both package.xml and scmlog.txt file will be sent as an email attachment while for Sandbox build only package.xml file will be sent.
  2. Trigger another build, in the on the successful deployment of the current build.
  3. Set the code coverage limit, for the deployment of a build.

 

2. Version Control

  1. Choose one of the registered Version Control Systems (VCS). Currently, AutoRABIT supports Version Control Systems like GIT, SVN, TFS and Perforce
  2. Based on the VCS selection, you are required to fill the respective details as given below:
    • SVN/GIT/TFS: Repository, Branch Name, Baseline Revision number and the respective user.
    • Perforce: Repository, Depot and Stream name from the drop down list. Additionally give a start revision number and add an user.​​​​​​
Note: Ensure that the metadata is committed under .SRC folder in the repository.
  1. Next, AutoRABIT allows you to commit build to build changes either Incremental or All. 

  • Incremental: Incremental Builds are critical for fast Continuous Builds.  Incremental Builds substantially decrease build times by avoiding the execution of previous metadata that are not needed.

Incremental build will fetch all the metadata changes beyond the selected Baseline Revision till the successful deployed revision to the destination org.

On the next CI Job run, the previous Baseline Revision automatically gets changed to the successful deployed revision. Hence, there will be incredible increase in build time performance for large-project incremental builds when a change to a single file or small number of files is performed.

Note 1: For the first CI job to run, you need to choose the Baseline Revision of your selected Version Control Repository.
Note 2: When you wish to perform Git Merge-operation from one branch to another, you are requested to select the correct 
development start revision (from source branch) since it will get all revisions from source branch to destination branch 
based on the commit date and generate new merged revision.
  • All: This option will fetch all the metadata after the selected branching Baseline Revision and it would not change the deployed revision.

 

Additional Settings

  1. Exclude metadata types:
  1. All the changes made to the metadata are displayed.
  2. You can select the metadata types that you want to exclude from an AutoRABIT build deployment.

  1. Profile settings:
  1. Retain login IP ranges : If you want to login with a particular Salesforce org you have an option to restrict IP ranges. By selecting Retain login IP ranges, the destination Salesforce org or version control system, you can retain the IP ranges.
  2. Retain User Permissions :You can retain the user permissions of the metadata types in the destination org or version control system.

Integrate ALM Workflow for IBMRTC (IBM - Rational Team Concert)
  1. Select Integrate ALM Workflow. A screen is displayed with mapped project and all the available work item types and its status are displayed as per the work flow defined in the ALM system, with respect to the work item type.
  2. Configure work item type status to include in the build in the succeeding window.
  3. Click OK.


 

Integrate ALM Workflow for JIRA
  1. Select Integrate ALM WorkflowA screen is displayed with mapped project and all the available work item types and its status are displayed as per the work flow defined in the ALM system, with respect to the work item type.
  2. Configure work item type status to include in the build, in the succeeding below window.
  3. Click OK.

  1. Post build activities

You have an option to execute post-build activities like:

  1. Sending an email notification along with files (package.Xml and scmlog.txt file) on the success and failure of a build. If the build is of Version Control then both package.xml and scmlog.txt file will be sent as an email attachment while for Sandbox build only package.xml file will be sent.
  2. Trigger another build, in the on the successful deployment of the current build.
  3. Set the code coverage limit, for the deployment of a build.

Deployment

This step defines the deployment definition. You will need to select the deployment agent and the destination deployment Org into which metadata changes will be deployed.

Note: In case, you don’t wish to automate the deployments for every build, please deselect the “DEPLOY” and “TEST “check boxes at the
top of the build settings step in the wizard.
  1. Select the deployment agent in Deployment Agents.
  2. Select the deployment Org in Deployment Org.
  3. Next, you can choose from the following options:
    1. Select Validate Only, to validate all the deployments.  
    2. Select Ignore visibility settings while deploying Profiles and PermissionSets.
    3. Enable Rollback will allow you to keep a copy of the changes before deployment and can revert the changes later.
    4. Run Destructive Changes: This option is available only if we select deployment in CI job setting. If this option is selected the listed destructive members in build, will be deleted from destination Salesforce org. If this build is used in custom deployment destructive members will not be a part of deployment.

A. Post Deployment Activities

You have an option to execute post-build activities like:

  1. Sending an email notification on the success and failure of a build.
  2. Trigger another build, in the on the successful deployment of the current build.
  3. Run Post Migration Process.

B. For IBMRTC (IBM - Rational Team Concert)

  1. Configure work item type status to include in the build.
  2. Click OK.

 

C. For JIRA

  1. Configure work item type status to include in the build.
  2. Click OK

 

Test

Select the required Test Agent.

Apex Tests & Code Coverage

The Code Coverage report provides information about the apex tests that are run, the classes that are covered, and the assertions that have failed and provides a percentage of the code that is covered by the test execution.

In Test Level, you can select a test type to run after a deployment has been successful. Select the level of testing from the 5 options:

  • No Test Run: Build is deployed without running any test cases.
  • Run All Tests In Org: All tests are run. The tests include all tests in your organization, including tests of managed packages.
  • Run Local Tests: All tests in your organization are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers
  • Run Specified Tests: This option allows the user to run specific Apex test classes post deployment.

  • Run Tests Based on Changes: This option allows the user to run dependent test based on build changes. Upon selection, a new dialog box will appear.
    • Note 1: Please make sure to execute all apex test before configuring this option. This allows you to configure the mapping between main class and test class.
    • Note 2: If you have cleared last run history in your destination org, again you are required to execute run all test. If not done, the dependent test execution will fail.
    • Note 3: If you have refreshed your sandbox, then again you are required to execute run all test. If not done, the dependent test execution will fail.

​​​​​​​

Functional Tests

After successful deployments we run functional test cases, to test the functionality of the code.

We have two options to fetch Test cases:

  1. TAF Labels
  2. Version Control

1. TAF Labels

The test labels that are present in our TAF module are displayed here.

  1. Select TAF Labels.
  2. In the pop-up, select the test labels to be run and click OK.

 

2. Version Control
  1. TAF: If we select TAF all the test cases committed to a particular branch in version control using TAF, they are displayed.
    1. Select Version Control in Test Cases.
    2. Select Label Type as TAF.
    3. Select the Repository Type.
    4. Enter the Repository Root and Branch.

 

  1. Selenium: The test scripts present in that particular version control branch are executed after successful deployment will be executed.

Note: For Selenium, the deployment org has to be authenticated using the user name and password only. If it is authenticated using OAuth, the functional test will not run.

  

  1. Provar: The test scripts in version control branch will be pulled and similar to selenium.

Schedule

AutoRABIT builds can be triggered daily or weekly:

  1. The schedules can be configured at any specified interval, for example, for every “X” hours.
  2. Daily schedule - the builds can be triggered at an appointed time in a day.
  3. Weekly schedule- at a specific time on a chosen week day.
  4. Build on commit- Apart from the normal scheduling, when we select the option to fetch changes from version control system, you can see the option Build on Commit. A new build is triggered, when changes are committed to the mapped version control system.

Configuring Web hook

For triggering the builds when changes are committed to the version control system in AutoRABIT, web hooks needs to be configured in the respective version control systems.

A. Configure a webhook in GIT
  1. Login to your GIT account, open a repository in which you want to configure a webhook, and go to Settings.

 

 
  1. Select Webhooks & services, and select Add webhook.

  1. Fill in the details and click Add webhook.

Payload URL format:
InstanceURL/autorabitrest/webhook/triggerSCMPushrequest

For example, if the instance is https://login.autorabit, then the payload URL would be:
https:// login.autorabit.com/ autorabitrest/webhook/triggerSCMPushrequest

  

B. Configure a webhook in Visual Studio GIT
  1. Login to your visual studio GIT account, select the repository in which you want to configure a webhook, and go to Settings.
  2. Select Service Hooks.
  3. Select Web hooks and click on next icon.

 

  1. Select Code push and Repository and click on Next as shown in below screen.

 

  1. Enter the URL as provided in the autoRABIT user guide and click on finish:

        InstanceURL/autorabitrest/webhook/triggerSCMPushrequest

For example, if the instance is https://login.autorabit, then the payload URL would be:
https:// login.autorabit.com/ autorabitrest/webhook/triggerSCMPushrequest

 

  1. You have successfully configured a webhook in visual studio GIT.
C. Configure a webhook in AWS Code Commit
  1. Login to the Amazon console provided.
  2. Click on Services and then click on Simple Notification Service.

 

  1. Select Topics > Create new topic. A dialog box appears.

 

  1. In Create new topic section, do the following:
    1. Enter the topic name in Topic Name field.
    2. Enter the Display name. Click the Create topic button.

 

  1. Select the AutoRABIT topic from the list of topics; Go to Actions section and select Subscribe to topic.

 

  1. A new window is displayed that allows you to create the subscription.
    1. Select HTTPS from the drop down in Protocol field.
    2. Enter Endpoint URL as provided in the user guide.

URL format: InstanceURL/autorabitrest/webhook/triggerSCMPushrequest

For example, if the instance is https://login.autorabit, then the payload URL would be:
https:// login.autorabit.com/ autorabitrest/webhook/triggerSCMPushrequest

 

  1. After clicking on Create subscription option, a successful notification message will appear.
  2. On subscription main page, you can find the subscription list with the above mentioned end point.
  3. Click on Services and then click on CodeCommit.

 

  1. Next, AWS code commit dashboard page gets displayed. From the list of repositories available, select the repository for which Build on commit need to configure.

 

  1. Selected repository will be shown in the next page. Then, click on Triggers.

 

  1. Enter the required details as shown below. The SNS topic must be selected which has been created at Step No. 3. 

 

  1. After clicking on Create button, the trigger is created. The list of triggers can be also be seen in the same page. See the screenshot below for your reference.

 

  1. By this step the configuration parts ends. Creation of the CI job and Build on commit will work for every commit to the repository.
D. Configure a webhook in Bitbucket 
  1. Login to your Bitbucket account and select a Repository, in which you want to configure a Webhook.

2. Click Settings and select Webhooks.

    URL format: InstanceURL/autorabitrest/webhook/triggerSCMPushrequest

For example, if the instance is https://login.autorabit, then the payload URL would be:
https:// login.autorabit.com/ autorabitrest/webhook/triggerSCMPushrequest

  1. Now fill in the details and click Save.

E. Configure a webhook in SVN

There will be a hook script shared with the IT team. For more details, contact: support@autorabit.com.

F. Configure a webhook in TFS
  1. Login as Admin to TFS account, go to Settings, and select Usage.
  2. Select a project.

  1. In the succeeding page, click Service Hooks.

  1. Click Create a new subscription.
  2. In the succeeding screen, select Webhooks.
  3. Click Next.

  1. In Trigger on this type of event, select Code checked in.
  2. Click Next.

  1. Give the instance URL : URL format: InstanceURL/autorabitrest/webhook/triggerSCMPushrequest

For example, if the instance is https://login.autorabit, then the payload URL would be :
https:// login.autorabit.com/ autorabitrest/webhook/triggerSCMPushrequest

  1. Click Finish.

 

ALM & Test Settings

A project can be mapped to various application life cycle management systems. These systems have to be registered with AutoRABIT as plug-ins by an administrator.

  • AutoRABIT fetches information from mapped Application Life cycle Management systems and provides reports such as sprint reports and test case reports in the dashboard. These are project-level settings:
  • Select the required browsers where the testing is to be done.
  • Select the test type from Test Type.
  • Set the minimum and maximum Dial Tolerance limits. These limits are displayed in the project dashboard.
  • The categories of tests include Platinum, Gold, Bronze, and Silver, in the decreasing order of importance. For example, you should include a test case with the highest priority in the platinum category and a test case with the least priority in the Silver category. Note that you can set the tolerance limits based on the type of test selected.
    • Platinum – Include test cases that should pass in this category.
    • Gold – Include test cases with lesser significance than those included in the Platinum category.
    • Bronze - Include test cases with lesser significance than those included in the Gold category.
    • Silver - Include test cases with lesser significance than those included in the Bronze category.
Module Settings
  1. Configure the test settings for a module.
  2. You can set separate dial and category tolerance limits to the modules of a project.

Set project test settings to modules

You can apply the overall project test settings, (which are applied in the ALM and Test Settings page of the project creation wizard) to all the modules created by selecting Set project test settings to modules.

To set tolerance limits to the added modules:

  1. Go to a module and set the maximum and minimum dial tolerance or category tolerance limits.
  2. Click Finish to complete the creation of a project. Your project is now configured on AutoRABIT.
  • Was this article helpful?