A blog dedicated to Salesforce Ohana

Implementing Continuous Integration Using Jenkins and Git for Salesforce Development

Continuous Integration (CI) is a development practice the allows developers to check-in their changes into a shared repository unlimited number of times. Each check-in is then verified by an automated build system, thus eliminating the changes of breaking some other part of the application while fixing one part.

By implementing Continuous Integration, you can detect errors quickly and locate them more easily. I always recommend to implement Continuous Integration in any kind of software projects. I personally implemented CI multiple times for Java and C++ projects in my career. Now last week, I implemented the same for Salesforce development. In today's post, I will explain how to do that.

Below are the prerequisite softwares -
Before we go further, I recommend you to go through the below posts to understand the concept.
Below picture will give you a high level overview about what I am going to achieve by implementing CI.

Step 1 - 
Install Jenkins on your local machine by downloading the Java Web Archive (.war) from here. Once downloaded, execute the below command from the directory where you have saved -
java -jar jenkins.war
After that open your browser and go to http://localhost:8080/. You will find that Jenkins is running on your local machine. Great!! So you have successfully configured Jenkins on your local machine.

Step 2 -
In this step, we will install Git plugin. You can do that by clicking on Manage Jenkins | Manage Plugins | Available and search for Git. Select Git Plugin to install the plugin and the restart your Jenkins.

Step 3 -
In this step, we will configure Jenkins by giving JDK, Git and Ant installation location. You can do that by clicking on Manage Jenkins | Configure System. Below is the screenshot from my system -
  
Step 4 -
In this step, we will setup Bitbucket account.
For that we need to generate SSH key for authentication. You can use eclipse to generate SSH key. Once you generate your SSH key, please upload the public key in Bitbucket by "Manage Account | Security | SSH Keys | Add Key". You need to save the private key with extension "ppk" in your local machine.

Step 5 -
In this step, we will configure our eclipse workspace for Sandbox 1 and check-in the code into Bitbucket repository.

To do that, first we need to download the Force.com Migration tool from Sandbox. Once downloaded, create a folder "lib" in eclipse and add the ant-salesforce.jar file there. After that add build.xml, build.properties and package.xml

Once added, please check-in the code into your bitbucket repository. 

Step 6 -
Now we will create a new projects in Jenkins by navigating "Home Page | New Item". Give appropriate name and choose "Freestyle project" as displayed below -
In the "Source Code Management" we need to choose Git. Here we need to provide the Git repository URL (Please provide Bitbucket URL for SSH Protocol). For connecting to Git repository, we need to add credentials also. For credential, click on "Add" button, choose "SSH Username with private key".
Provide username and paste the key saved in "ppk" file (Step 4).
Below is the screenshot -
Step 7 -
In this step, we need to prepare our build.xml, build.properties and package.xml so that it can fetch code from Sandbox 1 and deploy in Sandbox 2
Below is the build.xml -
<project name="Sudipta Deb - Continuous Integration Demo" default="test" basedir="." xmlns:sf="antlib:com.salesforce">

    <property file="build.properties"/>
    <property environment="env"/>

    <target name="fetchChanges">
        <sf:retrieve username="${sf1.username}"
                     password="${sf1.password}"
                     serverurl="${sf1.serverurl}"
                     retrieveTarget="src"
                     unpackaged="package.xml"/>
    </target>
    
    <target name="deploy">
        <sf:deploy username="${sf2.username}" 
                     password="${sf2.password}" 
                     serverurl="${sf2.serverurl}" 
                     deployRoot="src"
                   runAllTests="true"
                   logType="Detail" />
    </target>
</project>

build.properties - (Note: Personally I don't like giving username+password details in build.properties file, rather I will give those details in next step while configuring ant build step.)
sf1.serverurl = https://test.salesforce.com
sf2.serverurl = https://login.salesforce.com
package.xml -
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>*</members>
        <name>CustomObject</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexClass</name>
    </types>
    <types>
        <members>*</members>
        <name>ApexPage</name>
    </types>
    <version>33.0</version>
</Package>


Step 8 -
Here we will configure how frequently Jenkins should check for changes and start build process. For that we need to choose "Poll SCM" option and give "H/15 * * * *" as schedule which will make sure that every 15 mins Jenkins will check for new changes. Below is the screenshot -

Step 9 -
Now we need to add build steps. We can do that by Build | Add Build Steps | Invoke Ant. Here is the step -

Step 10 -
Now we will add post build step which will send the build notification email. Below is the setup -

We are done. Now we can use Jenkins to first retrieve the changes from Sandbox 1, then execute the test cases and finally deploy the changes into Sandbox 2.

I hope now you can configure Continuous Integration for Salesforce Development. Please provide me your feedback. Thanks in advance.


Share:

20 comments:

  1. Sudipta, Very nice article on the CI integration pattern. I used Drone as CI with bitbucket + eclipse. Currently, each time code is pushed into bitbucket, it triggers build of the ant script which takes the whole src folder from the repository and deploys it into a sandbox. My intention is actually to push only the changes(for example only the class that is changed) and not the whole source folder.I tried using the target 'fetchChanges' as shown in your build.xml, but looks like it retrieves the whole source folder and not just the changes, is it possible only to deploy the changed class file for example(without specifying it in the package.xml) ?

    ReplyDelete
  2. Sudipta, Very nice article on the CI integration pattern. I used Drone as CI with bitbucket + eclipse. Currently, each time code is pushed into bitbucket, it triggers build of the ant script which takes the whole src folder from the repository and deploys it into a sandbox. My intention is actually to push only the changes(for example only the class that is changed) and not the whole source folder.I tried using the target 'fetchChanges' as shown in your build.xml, but looks like it retrieves the whole source folder and not just the changes, is it possible only to deploy the changed class file for example(without specifying it in the package.xml) ?

    ReplyDelete
  3. How is this polling for changes? Looking at the Package.xml, it appears that it just retrieves everything and deploys it from the src to the target. I'm not very good with git and don't use bitbucket, is there some step that is using Jenkins to pull the diff of the latest push and HEAD^ and generate the Package.xml with just the changed metadata?

    ReplyDelete
  4. hello admin.i am truly cherish it your blog.Because your clarification insightful every one of the themes are excessively good.I got enough information from your blog.Thanks for sharing more.. Devops Training in Bangalore
    Devops Training Institute in Bangalore
    Best Devops Training in Bangalore

    ReplyDelete
  5. I acknowledge the author for his brilliant work for making this exceptionally useful and informative content to guide us.
    salesforce form builder

    ReplyDelete
  6. Nice information my sincere thanks for sharing this post Please Continue to share this post
    Devops Training in Bangalore

    ReplyDelete
  7. Very nice Blog relating SalesForce Development with Jenkins and Git Thank you Sharing.

    Devops Training

    ReplyDelete
  8. Very Nice Blog on Continuous integration... Thank you for the Blog.
    Devops Training in Bangalore"

    ReplyDelete
  9. It has been simply incredibly generous with you to provide openly
    what exactly many individuals would’ve marketed for an eBook to end
    up making some cash for their end, primarily given that you could
    have tried it in the event you wanted.


    aws training in chennai



    aws training in bangalore

    ReplyDelete
  10. Thank you a lot for providing individuals with a very
    spectacular possibility to read critical reviews from this site.


    aws training in bangalore



    aws training in chennai


    ReplyDelete
  11. Your good knowledge and kindness in playing with all the pieces were
    very useful. I don’t know what I would have done if I had not
    encountered such a step like this.


    aws training in bangalore



    aws training in chennai

    ReplyDelete
  12. Those guidelines additionally worked to become a good way to
    recognize that other people online have the identical fervor like mine
    to grasp great deal more around this condition.


    aws training in bangalore



    aws training in chennai

    ReplyDelete
  13. Those guidelines additionally worked to become a good way to
    recognize that other people online have the identical fervor like mine
    to grasp great deal more around this condition.



    aws training in bangalore



    aws training in chennai

    ReplyDelete
  14. I simply wanted to write down a quick word to say thanks to you for those wonderful tips and hints you are showing on this site.

    python training in bangalore

    ReplyDelete
  15. Nice Blog and You Writing Skills Are Top Notch........
    Thanks@Salesforce Developer Training

    ReplyDelete
  16. Thanks for the great post.....@ Sudipta De.
    Thanks's For sharing....
    With regards.....
    https://www.svrtechnologies.com/salesforce-developer/salesforce-developer-training

    ReplyDelete
  17. @sudipta. Just one point, in the above scenario, you are migrating the package.xml from one sandbox to another. Just for my understanding, if you commit something to the master branch, Jenkins should take that package.xml and deploy it to the target sandbox right?

    ReplyDelete

Follow Me

Enter your email address:

Delivered by FeedBurner

Popular Posts

Labels

Salesforce (95) Apex (42) admin (27) ADM (20) visualforce (20) dev 501 (19) integration (18) learn salesforce (17) 501 (16) SOAP (13) tutorial (11) Certification. (9) Trigger (7) lightning (7) test class (7) unit testing (7) design pattern (6) report (6) trailhead (6) Advanced Admin (5) New Features (5) SOQL (5) css (5) dashboard (5) debug (5) formula (5) javascript (5) mobile (5) salesforce release (5) security (5) service cloud (5) solution management (5) use case (5) JSON (4) Lightning Experience (4) WebSphere (4) best practice (4) cast iron (4) developer (4) github (4) html (4) polymer (4) profiles (4) responsive (4) tdd (4) ui (4) Live Chat (3) Performance (3) Products (3) Sales Cloud (3) Summer15 (3) Tips (3) component (3) deployment (3) dynamic apex (3) event (3) license (3) map (3) mapbox (3) singleton (3) version controlling (3) Advanced Apex (2) Bulkify (2) Distributed Version Controlling (2) Eclipse (2) Force.com IDE (2) Governor Limit (2) IBM (2) Lightning Design System (2) Live Agent (2) Price Book (2) REST (2) SOSL (2) Spring 15 (2) Study Notes. (2) Summer17 (2) ant (2) automation tool (2) basic (2) chatter (2) coding (2) communication (2) console (2) controller (2) documentation (2) flow (2) git (2) jquery (2) logging (2) permission (2) process builder (2) release (2) salesforce1 (2) strategy (2) xml (2) Agent Productivity (1) Asynchronous callout (1) Browser (1) Bulk data load (1) Calendar (1) Canon (1) Case Management (1) Classic (1) Contact Center (1) Continuation (1) Continuous Integration (1) Cookie (1) Custom Metadata (1) Custom Object (1) Decorator Design Pattern (1) Diwali (1) Email (1) Groups (1) Guide (1) Ideas (1) Improvement (1) KPIs (1) LastModifiedDate (1) Metadata (1) Metrics (1) Omni-Channel (1) Opportunity (1) Photo (1) Platform Developer I (1) Product Schedule (1) Profile (1) Public Site (1) Query Plan (1) QuickReference (1) Reports (1) Role (1) Salesforce Optimizer (1) Site (1) Skills (1) Snap-ins (1) Spring 17 (1) Summer14 (1) Summer16 (1) SystemModStamp (1) Users (1) Webservice (1) Winter'15 (1) Winter'17 (1) access (1) agile (1) app (1) approval process (1) aura (1) awesome (1) backup (1) bitbucket (1) book (1) campaign (1) change set (1) code (1) code coverage (1) configuration (1) csv (1) custom button (1) custom settings (1) customization (1) data loader (1) database (1) delegate Admin (1) describe (1) dom (1) dreamforce (1) duplicate (1) dynamic (1) equals (1) error (1) field-level security (1) folder (1) ftp (1) generic (1) gift (1) global describe (1) hashcode (1) import wizard (1) jenkins (1) keynote (1) long running requests (1) monitoring (1) mysql (1) object (1) page layout (1) personal (1) power of one (1) record type (1) relationship (1) request (1) review (1) sub-tab (1) tab (1) username (1) visual workflow (1) workflow (1)

My Trailhead

Total Subscribers

Total Pageviews