How to use SalesforceDX to deploy metadata in Sandboxes or Non-Scratch Salesforce instances
If you have existing VCS which stores metadata information about your Salesforce instance in old format, dependent on package.xml and you want to use Salesforce DXthen this blog post is for you. As you might already know, Salesforce DX does not need package.xml and can automatically detect changes in your Salesforce instance, therefore new Salesforce DX project format is different. In this blog post we will see, how Salesforce DX can be used without enabling Developer Hub and using Salesforce DX with normal Salesforce instances.
There are two solution to this problem
Keep using old Project format and use Metadata API to retrieve and deploy
Convert old project format to Salesforce DX project Format
Difference between Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
I have written many posts about Continuous Integrations and implemented many projects with capability of Continuous Delivery. However multiple times got into discussion on what exactly is difference between Continuous Integration, Continuous Delivery and Continuous Deployment. As SFDX is new way to develop and deploy changes in Salesforce, just thought to post a small post on basic difference between these terms.
Step by step guide to set up Continuous Integration (CI) for Salesforce using Team Foundation Server (TFS) with video tutorial
I have already written some Continuous Integration (CI) posts for Salesforce previously using different tools like Jenkins. In this blog post we will go through steps to use Microsoft Team Foundation Server (TFS) to set up Continuous Integration.
We can either use cloud based Team foundation Server (TFS) or locally installed on network. For ease, we would be using cloud based TFS for this blog post.
Step 1: Creating developer account on VisualStudio Online
Navigate to https://www.visualstudio.com/ and choose Get Started for free in Visual Studio Team Services section. You may need to create a new Microsoft developer account, if you don’t have it already.
Step 2: Using TFS as source code repository
Once we are able to login to TFS, lets start by creating a code repository. That’s right, you don’t need separate Bitbucket or Github account to save your code/metadata unlike in Jenkins. So, our start with TFS is really good and impressive till this point 🙂 . Wizard to create new project is self explanatory and would look like below image
Using open source PMD tool to generate code quality report for Apex classes
PMD is very well known source code analyzer for Java, android and many more languages. Good news for us (Salesforce developers) is , that it supports now Apex. You might be thinking how can we make PMD as part of our daily life ?
There are multiple ways
We can run static code analysis standalone
It can be part of ANT build to generate error reports
Jenkins can use it to generate nice report around code quality
Eclipse can use it as a plugin to generate report
In this blog post, we will discuss option 1, that is running it as a standalone application to generate code quality report.
Native Force.com solution for Continuous Integration using AppExchange product Flosum
This is first of many upcoming articles on evaluation of Salesforce AppExchange products. In this post we will be discussing capability of native Force.com based solution for Continuous integration. Deployment has always been one of pain point in Salesforce developement. I have worked and proposed many solutions to customers based on their requirement and budget. One of solution which got my attention recently is “Flosum” available and listed on AppExchange from this year.
I have used many traditional continuous integrations like Jenkins, Bamboo, Scheduled ANT script but all of them still involve manual intervention and most important, special skill set to setup and handle any issue arising time to time.
Let’s talk about Flosum and what makes it different at high level:
Complete native solution built over Force.com platform
Requirement gathering to deployment, all aspects covered
Multiple environment management
Easy Profile migration
Security access to environment for each user
Default space 11GB
Acts as Version Control
Supports Continuous integration and auto deployments
Compare Complete Org with historical or current changes
In previous article, I have explained that how to use Jenkins to setup Continuous integration for Salesforce.
Now, once Jenkins is up and its doing its job to build Salesforce changes. Next task is to monitor build result. We already setup post deployment task by creating chatter message to notify everyone about build result, however there is one more excellent way to be aware about result and its small desktop client named “CCTray”.
You can download CCTray from here. Once installed, follow below steps to setup.
As your Salesforce Organization undergoes heavy customization and frequent builds, moving changes from one Sandbox to other sandboxes starts taking longer time and effort. Also, in normal Salesforce project, there are chances that you will have minimum three sandboxes likely Developer Sandbox, QA Sandbox and UAT Sandbox. After some time you will be in need of some solution which can reduce your effort.
This time its Salesforce using Jenkins. In this article I will walk through solution of above problem using Jenkins. Don’t forget to watch Video at end of this article, where I provided demo of everything explained in this article.