Image may be NSFW.
Clik here to view.
At Dreamforce 2011, I had the pleasure of meeting Reid Carlberg, Jeff Douglas, Eric Magnuson and Richard Vanhook for the first time face to face, this alone was very exciting! I was co-presenting with them in a session entitled, ‘The New Frontier: PaaS and Open Source‘.
In that session we talked about our thoughts on building an open source community on the platform. While this idea had not fully formed then, I was observing the barrier to entry for anyone getting a cool bit of open source Apex into their org was quite high compared to other platforms. Especially given both are in the cloud. Sure packages helped, but that put the overhead on the author to update them as well as the repository. As well as leaving a potentially unwanted package definition in the developers org. New developers on the platform also often struggle with Ant and Eclipse, leaving them copy and pasting to get the code in, yuk!
Inspired by the GitHub Clone in Desktop button you see on Github. I’ve created a tool that will deploy directly from Github into a Salesforce org. Its been deployed in the cloud, using Heroku, so there is nothing to install. Simply click a custom link pointing to the desired repo, login to your org and the tool scans the repository for Salesforce files (or packages) and after a brief confirmation page, your one click away from having the code in your org!
To include such links in your README file, take the base URL of the following…
https://githubsfdeploy.herokuapp.com/app/githubdeploy
Then apply the owner and repository name, e.g.
https://githubsfdeploy.herokuapp.com/app/githubdeploy/financialforcedev/apex-mdapi
When visitors to your GitHub repo click such a link, they will be taken through an Salesforce oAuth login flow to their desired org, or if they are already logged in an initial prompt to confirm the app access needs are acceptable. Then they will see something like this…
Image may be NSFW.
Clik here to view.
Clicking Deploy starts the deployment giving feedback as Salesforce processes…
Image may be NSFW.
Clik here to view.
Having reviewed a number of GitHub repositories containing Apex code and various other Salesforce files. Some utilise the documented Metadata API folder structure with a package.xml committed. Others include only the Apex class files, without the metadata xml files that accompany them. The tool attempts to resolve these differences via the following.
- If a package.xml is found, it will include everything in that folder exclusively and utilise the package.xml when deploying.
- If no package.xml is found, it will attempt to dynamically generate one.
- If no metadata file for an Apex class, it will create one for it.
I’ve tested the tool with a number of other repositories I found Salesforce code in and this seems to cover the majority of use cases. However I’m sure there will be some others I’ve not discovered. Right now I would recommend using a package.xml for now with the correct structure. Though you can experiment with the auto package.xml creation feature, if this works for you, it saves you a job keeping that in sync as well!
NOTE: The tool does not run tests during the deployment, so will not deploy into production orgs, I may add a checkbox with a big disclaimer around it if there is demand. Bottom line this is a developer tool.
Try it out!
I hope this helps make our open source Salesforce projects even more accessible. I’ve now updated all the repositories I hang out in most often, check out Deploy to Salesforce links in the README files now. In the Apex Enterprise Patterns and its sample application repository (work in progress for upcoming Dreamforce 2013 session) and Apex Metadata API. Finally I’ve published the full source code for the tool here, feedback and ideas welcome!
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
