Blog

Home / Blog / Salesforce / Salesforce.com/Force.com Team Development
06Mar 2013

Salesforce.com/Force.com Team Development

About the Author

Carlos Eiroa Carlos Eiroa

Carlos loves writing high-quality object-oriented and functional code, and is a big fan of build tools, automated testing, and continuous integration. Specialized in building custom software applications, including AppExchange apps, in the Force.com SaaS platform. Carlos is a Certified Salesforce Advanced Developer, Certified Salesforce Developer, Certified Salesforce Administrator and Certified Java Programmer.

Comments (11)

sekar - March 8, 2013

Nice article. Simply superb!

Reply
EDwin - March 25, 2013

great article….one of the best I have seen that describes the gotcha’s.

I wonder…I never see anyone describe how to do do branching and merging in this environment….any hints on that?

Ideally, before pushing my changes to the CI server, I should pull down the latest from the CI server, run my tests and then push to the server

Reply
Carlos Eiroa
Carlos Eiroa - March 26, 2013

Hi Edwin,

I haven’t read anything about branching and merging in Saleforce projects either. I think we are all still trying to learn the basics and haven’t got that far. However, I think it should not be too different from branching and merging in other environments, with the added caveat that some Salesforce components are not part of the metadata and need to be migrated between orgs manually.

Regarding when to run the tests, in most other development environments (Java, .NET, PHP….) the sequence of steps would be as you say, with the tests running before deploying to the QA environment. However, these two steps are reversed when working with Salesforce. With Salesforce you can only run the tests from inside one of their orgs, so you don’t have any other option but to deploy first then run the tests. You will most likely be using Salesforce’s Ant Migration Tool to deploy the changes to the QA org. If so, you just need to include the “runalltests” property in the target, like this:

<target name="deployCodeToPackaging">

   <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" deployRoot="src" runAllTests="true"></sf:deploy>  

</target>

Regards,

Carlos

Reply
Raja Sampath - May 31, 2013

Nice article. We have a similar set up using SVN and Jenkins CI. However, we started running into problems with schedule jobs.

As we all know, Salesforce does not allow changes to classes referred in a scheduled job. However, Jenkins CI checks out head revision of trunk from SVN and errors out when ANT tries deploying the changes to sandbox. It is a tedious manual process to delete and recreate schedule jobs every time. We ended up deleting all scheduled jobs every time sandbox is refreshed from prod.

Do you have any workarounds or ideas?

Thanks
Raja

Reply
Aman - June 11, 2013

Very good article, indeed !

However, it would be great if you can talk about salesforce components which are not metadata API accessible i.e. components which have to managed manually in the Target orgs. That may affect CI to some extent.
Now in our enterprise development, we have really agile developments which need includes in-house developers, product vendors providing Managed package builds, ETL feeds. Testing in target org is imminent. Please share your inputs.

Reply
Carlos Eiroa
Carlos Eiroa - July 8, 2013

 

Hi Raja,

You are right, Salesforce does not let you deploy changes to classes that are referenced from a scheduled job. And as far as I can tell scheduled jobs are not yet exposed as metadata. Thus the only option is to do what you are doing, which is to manually delete the scheduled jobs from the org where the CI Server is deploying too.

Hopefully, as Salesforce continues to expose more elements through the metadata API, they will also expose scheduled jobs and then we will be able to make the automatic removal part of the build process.

Regards,

Carlos

Reply
Carlos Eiroa
Carlos Eiroa - July 8, 2013

 

Hi Aman,

There is a long list of items that are not available in the Metadata API, and that therefore need to be manually migrated between orgs. The list changes with every new release of the platform though, so it’s something to always be watching out for.

For these elements there is no other option but to manually re-apply the changes from one org to the others. I’d suggest having a central document where you keep track of all these components. You can either use something like GoogleDocs, or you can keep a text file as part of the project and thus under version control. Personally, I like the version control option better, and I like to keep track in this same document of which components have been manually deployed when.

Hope that helps. Regards,

Carlos

Reply
Ananth - August 12, 2013

Hi,

If we have to implement this feature “Continuous Integration and automation” in the current project using 2-3 resources what might be the estimated time to complete this process.

Please explain and help.

Regards,

Ananth.R.

Reply
Tom Snyder - September 29, 2013

Carlos, Nicely done.

Raja, One workaround that I do would be to create an object or custom setting to store the job name, scheduable class, and cron expression. Create a helper class with an abort and schedule method. Then just script these calls both before and after the deploy. Let me know if you need the code I could provide, on iPad right now.

-Tom

Reply
adam - December 14, 2013

Great article
Clear, practical and to the point
I have been going trough so much bad sales force documentation lately
You should write a book

Reply
Mitchell McConnell - September 23, 2014

Carlos,

Muchas gracias por este articulo!

This and its companion article were exactly what I was looking for, and very well done.

Mitch

Reply

Leave a Reply