Skip to main content
AutoRABIT, Inc.

Create New Job

 

This section allows you to create a New CI Job. Please find below the steps involved in creating a CI Job.

Project Configuration

Pre-requisites:

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

To create a new project:

  1. Click the Projects in the AutoRABIT toolbar. It launches a project list view where all the projects are displayed.
  2. Click Create New Project to open a project creation wizard. The wizard contains four tabs:
    • Project Details
    • Build
    • Plug-ins
    • Settings

Project Details


Provide the following details:

  1. Enter a project name in Project Name.
  2. Select the type of the project in Project Type.
  3. Select project visibility. By default, project visibility is set to Everyone.
  4. The Project is set to active by default during the creation of a project. If you want to halt the project in between or stop creating builds and other functions, you can unselect the option.
  5. Optionally, enter a description.

Functional Modules

AutoRABIT project can contain any 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 are generated.
In the Functional Modules section, you have an option to either add or delete a module.

  1. Click Add functional module to add a module.
  2. Or select the required module and click Delete functional module to delete a module.

Build Settings

Build Settings provides the Build-Install-Test configuration settings to deploy and test the metadata changes into a Sandbox from either version control system or another Sandbox in a scheduled manner as well as on-demand enabling Continuous Integration .

Build

Select the Build, Deploy, Test agents and Static Analysis.

You can configure only the selected options in the Build Settings page.

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 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.

  1. Build master server details on which a build has to be triggered.
  2. For a build, the metadata can be fetched from two sources:

    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.

    • Salesforce Org - If development team makes their changes directly in Salesforce Orgs without any source control system.

    • 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.

Salesforce Org

You can click View Details to view the complete details of the selected source. The following screen shows the deails of a selected source.

There are three packaging options available in AutoRABIT  for retreiving and bundling the changes from a source sandbox, namely, Unmanaged, Managed and Unpackaged.  A brief note on packages is mentioned here.
Unmanaged packages

Unmanaged packages are typically used to 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.

As new components get developed in the Organization , they should be added to the unmanaged package for them to be available in the destination after deployment.

Here you have an option to select:

  1. In Salesforce Org(Source), choose the source sandbox to fetch the metadata members from.
  2. In Package Type, select the type of package to be use:                                                                                                                                                                              Managed packages : Managed packages are typically used by Salesforce partners to distribute and sell applications to customers. These packages must be created from a Develer 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.

  3. 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

    Unpackaged Mode

    However , there is a third packaging option, “unpackaged” that AutoRABIT supports for development teams who work in Sandboxes on their metadata components , but not necessarily create a package of the metadata components.
    Unpackaged mode fetches all the metadata members present in the Organization that has got modified from the last AutoRABIT cycle .
    In case of unmanaged package, enter name of the package of the selected Salesforce   Organization from which the data has to be retrieved for the field - SourcePackage

  4. If you choose Managed you should specify the Source Namespace and Destination Namespace.
  5. Optionally, you can auto-commit changes to source control.

    Changes made to the code are committed to the version control system of the selected user.

    Changes made by multiple users are committed to the version control system.

    • Single User Commit
    • User Based Commit
  6. Additional Settings:

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

    • Exclude metadata types

      If this option is selected Destructive changes will be generated based on CI job source
      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.
      CI job source is version control: We are listing destructive members based on deleted files in between given start revision and head revision.

      If a managed package is installed in a Salesforce org on a partiuclar 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.

      • Prepare destructive changes:
      • Exclude baseline managed packages changes:
      • IncludePicklist modifications:

      You can retain the user persmissions of the metadata types in the destination org or version control system.

       

      • Profile Settings

        If you want to login with a particlular Saleforce org you have an option to resrtict IP ranges. By selecting Retain login IP ranges, the destination Salesforce org or version control system, you can retain the IP ranges.

        • Retain login IP ranges
        • Retain User Permissions
  7. If you select this option, select the version control system, and fill in the details:
    • For SVN, give Repository URL, User name, and Password.
    • For GIT, select the Git Repository,Branch and give the User name, and Password.
    • For TFS, give the Repository URL, Project path,User name, and Password.
Post build 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. Set the code coverage limit, for the deployment of a build.

Version Control Details

 

 Ensure that the metadata is committed under .src folder in the repository.

  1. Select the version control system, and fill in the details:
    • For SVN, give Repository URL, User name, and Password.
    • For GIT select the Git Repository,Branch and give the user name, and password.
    • For TFS,give the repository URL, project path, user name, and password.
  2. In Additional Settings, you can:
    • Exclude metadata types : All the changes made to the metadata are displayed and you can select the metadata types that you want to exclude from an AutoRABIT build deployment.

 

Profile settings:

Retain login IP ranges : If you want to login with a particlular Saleforce org you have an option to resrtict IP ranges. By selecting Retain login IP ranges, the destination Salesforce org or version control system, you can retain the IP ranges.

                  Retain User Permissions :You can retain the user persmissions of the metadata types in the destination org or version control system.

  1. Integrate ALM Workflow for IBMRTC

     

    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.


    Integrate ALM Workflow for JIRA

    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.

    Post build activities

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

    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.

    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.

     an Admin cannot delete another Admin.

     

    Post deployment activities

    You have an option to execute post-deployment activities, like:

    For IBMRTC


    For JIRA

     

    Assigning a Test Agent

    Select the required Test Agent and the Org in which the Code Coverage tests should run.

    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 4 options:

    Build is deployed without running any test cases.

    All tests are run. The tests include all tests in your organization, including tests of managed packages.

    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

    This option allows the user to run specific Apex test classes post deployment.


    (For more details go to Page no: 107)

     

    Scheduling a Build

    Changes fetched from Salesforce Org:

    1. AutoRABIT builds can be triggered daily or weekly:
    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. The schedules can be configured at specified interval, for example, for every “X” hours.

Changes fetched from a Version Control System

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 I AutoRABIT, web hooks have to be configured in the respective version control systems.
For GIT
For configuring a webhook in GIT: Login to your GIT account, open a repository in which you want to configure a webhook, and go to Settings.

 

 

Select Webhooks & services, and select 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

  Fill in the details and click Add webhook.

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

For Bitbucket
For configuring a webhook in Bitbucket:

  • Login to your Bitbucket account and select a repository, in which you want to configure a webhook.


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

For configuring a webhook in TFS:

  • Login as Admin to TFS account, go to Settings, and select Usage.
  • Select a project.

In the succeeding page, click Service Hooks.

  • Click Create a new subscription
  • In the succeeding screen, select Webhooks
  • Click Next.

In Trigger on this type of event, select Code checked in.

Click Next.

  • 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

  • Click Finish.

 

ALM 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

To configure the test settings for a module:

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. Select Integrate ALM Workflow
  2. Configure work item type status to include in the build in the succeeding window.
  3. Click OK
  4. Select Integrate ALM Workflow
  5. Configure work item type status to include in the build, in the succeeding below window.
  6. Click OK.
  7. Sending an email notification on the success and failure of a build.
  8. If there is a dependency project, a new build is triggered and deployed in the selected project
  9. You can trigger a new build in the dependent project, and after the build is successful, the data is deployed into the mapped Salesforce Org.
  10. Select the deployment agent in Deployment Agents.
  11. Select the deployment Org in Deployment Org.
  12. Or select Validate Only, to validate all the deployments. 
  13. Select Igonore visibility settings while deploying Profiles and PermissionSets.
  14. 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.
  15. Sending an email notification on the success and failure of a deployment.
  16. Set ALM work item status that has to be updated after the success or failure of a deployment, and the status is reflected in your mapped ALM system after the deployment.
  • Configure work item type status to include in the build.
  • Click OK
  • Configure work item type status to include in the build.
  • Click OK
  • No Test Run
  • Run All Tests In Org
  • Run Local Tests
  • Run Specified Tests
  • AutoRABIT builds can be triggered daily or weekly:
  • Daily schedule - the builds can be triggered at an appointed time in a day.
  • Weekly schedule- at a specific time on a chosen week day.
  • The schedules can be configured at specified interval, for example, for every “X” hours.
  • AutoRABIT builds can be triggered daily or weekly:
  • Daily schedule - the builds can be triggered at an appointed time in a day.
  • Weekly schedule- at a specific time on a chosen week day.
  • The schedules can be configured at specified interval, for example, for every “X” hours.
  • Login to your GIT account, open a repository in which you want to configure a webhook, and go to Settings.
  • Select Webhooks & services, and select Add webhook.
  • Fill in the details and click Add webhook.
  • Login to your Bitbucket account and select a repository, in which you want to configure a webhook.
  • Click Settings and select Webhooks
  • Now fill in the details and click Save.
  • Login as Admin to TFS account, go to Settings, and select Usage.
  • Select a project.
  • In the succeeding page, click Service Hooks.
  • Click Create a new subscription
  • In the succeeding screen, select Webhooks
  • Click Next.
  • In Trigger on this type of event, select Code checked in.
  • Click Next.
  • Give the instance URL : URL format: InstanceURL/autorabitrest/webhook/triggerSCMPushrequest
  • Click Finish.
  • 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.
  • Go to a module and set the maximum and minimum dial tolerance or category tolerance limits.
  • Click Finish to complete the creation of a project.
  • Was this article helpful?