One of the key goals for creating Gearset Deploy has been to make deployments to your Salesforce orgs as simple and painless as possible. If you develop for the Salesforce platform and need to perform deployments, you’ll be well aware that it can involve a number of repeated manual steps. One way to automate this process is through the implementation of a continuous integration development process.
Continuous integration allows the scheduling of when you decide to merge developer working copies to a shared main repository. The benefits for an individual or development teams can be significant. Continuous integration can reduce integration bugs and keep the main repository current, thus saving time taken to perform deployments. It’s a fundamental part of effective release management, as set out in our recent whitepaper that’s available as a free download.
We’ve already added support for comparing GitHub repositories with your Salesforce organizations. Check out our recent blog post about this new feature and how easy it is to select your GitHub repo to use as the source organization during deployment.
With this new feature, you can easily view changes in your source control system and deploy metadata directly to your Salesforce organizations.
The next step is to support the automation of a continuous integration process within Gearset Deploy. Simply put, we’re adding the ability to easily choose the source and target orgs, the frequency of which you want the job(s) to run and provide a detailed history of those jobs should you ever need to examine the changes made.
We’re working hard on this new feature right now and the first version will be available shortly for you to try. In the meantime, here’s a preview of the designs to show you just how easily you can begin implementing a CI type process by using Gearset Deploy with its latest features such as GitHub support.
Continuous integration design preview
Step 1
To begin the process of creating a CI job using Gearset Deploy, start by visiting the ‘Manage CI jobs’ tab.
Step 2
Select the source and target Salesforce organizations that you want to create the CI job for and the frequency of which the CI job should run (daily, weekly, monthly) and save the specified schedule. That’s all there is to it in terms of setting up the CI process for your development process.
What happens after a job has run?
After each job has run, you’ll get an email confirming that it has run successfully, or if the job has failed. You can easily access a complete history of each scheduled job that is set to run.
You obviously don’t want to just see the set of jobs that are currently set to run. You can view a complete history of all the times the job has actually run and the changes deployed from the source organization to your target organization. This can be invaluable for having an audit trail of changes made to your orgs, implementing a CI process that will save you time, and lead to more efficient and less error prone deployments.
Conclusion
This preview is for our first implementation of this new feature, but we’ve got further enhancements in the works that mean we’ll be able to handle more complex continuous integration scenarios over time. Visit our forum to add your comments and suggestions, or drop us an email at [email protected] and give us your thoughts!