Salesforce1 Developer Week London

In case you weren’t aware, Salesforce1 Developer Week took place at the end of April 2014 - in fact it seems to have been more than a week judging by the events on the official blog page.

The London event took place on 30th April, kindly hosted by TQuila at their headquarters in Lindsay Street.  Registrations took a bit of a hit when strike on the underground was announced to coincide with this, but on the day more than 50 people attended - an excellent effort.

After pizza and beers, the evening was kicked off with a presentation on possibilities of the Salesforce1 mobile application, from a configuration and programmatic perspective from myself and Richard Clark, CTO of Make Positive:

  

 

 

 

 

 

 The attendees then retired to the main "cabin" of the office to crack on with the workbooks, mini-hacks or simply to solve some real-world problems they had been struggling with:

From time to time the best practice discussions became heated :)

but we were all friends again after an hour or so of hacking, and it was back to the presentation area to demonstrate what had been built:

Something that really stood out for me was the contrast with the Elevate mobile workshop that took place in London in March.  There, a fair amount of time was spent setting up the environment, especially for android development involving the emulator, and most people had to push hard to get through the workbook in a whole day.  This time around, everyone was up and running without incident, and my time as a helper was spent advising how business problems could be solved using the application.

If you were unable to attend a Salesforce1 Developer Week event, you can still try the workbook and hacks yourself using the following links:

• Workbook: http://bit.ly/1rEAWcL
• Hacks: http://bit.ly/1n1dGpn

Our next event takes place on Wednesday 14th May at the Appirio offices near Bond Street station. Christophe Coenraets, Salesforce Developer Envangelist, will be joining us for a talk on Angular.js and Ionic.  I’ve followed a lot of Christophe’s community activity at both Adobe and Salesforce.com and he’s done some interesting work, so I’m really looking forward to this.  You can signup for this event on the meetup page.

Follow @bob_buzzard

Second London Force.com Developer Meetup / Deploying

This week saw the second London Force.com Developer Meetup at the Skills Matter eXchange, with a three handed talk on Team Development Strategies on the Force.com Platform from Wes Nolte, Anup Jadhav and Laurent Delcambre.  This time the meetup was captured on video - you can view it at: http://skillsmatter.com/podcast/nosql/team-development-strategies. There were also prizes on offer for answering snap questions from the presenters - I managed to come away with a Ruby on Rails book and a Salesforce.com T-Shirt.


One of the more interesting topics of discussion for me was around deploying changes between sandbox and production.  Like many Force.com developers I suspect, all my early deployments were carried out using the Force.com IDE, highlighting the elements I wanted to deploy, right-clicking and going through the deploy to server wizard.  This gives a nice visual indicator of the changes that will be made on the target system:

However, there are a couple of downsides to this:

• If the deployment fails, you have to start over from scratch.  Not too bad if there's only a couple of files like my example deployment above, but a bit tedious once you get into double figures.
• The changes aren't repeatable.  If I want to deploy those same files to another org at a later date, that's only possible if no additional changes have been made.

For these reasons I tend to use change sets these days, although these only work between connected organizations (e.g. sandbox to production or between sandboxes associated with the same production org).

Change sets are persistent, so when working on a piece of development you can add the new/changed elements as they are created.  Once you are ready to deploy, you upload the change set to the target org which locks the elements in their current form.  This means that if you need to deploy to a separate org (a training sandbox for example), it doesn't matter when you do this, the change set will be in exactly the same state as when it was first uploaded.  I've found this aspect to be particularly useful when I have a large amount of changes to deploy to production - I can test out deploying to a pre-production sandbox and once I've ironed out the issues, I can simply "replay" the change set into production.

If the deployment of a change set fails, you can simply clone the change set, fix the problem and then upload it again.  An important point to note is that when you clone the change set, you get the latest version of each of the elements in the new change set.

Change sets aren't a silver bullet though - being limited to connected org means that you must be developing in a sandbox to use them.  If you are working in a Developer Edition, they won't be available.  They also tend to be slower than using the IDE - something that can become important when you have to wait 30 minutes for the latest attempt at the change set to be uploaded at 1am in the morning.  Less of a regular issue, but still an issue nonetheless, is that they tend to be fragile around Salesforce.com releases - sometimes the upload takes a couple of days to become available, while at other times it doesn't make its way to the target org at all.  I'd imagine this is down to the source and target orgs being at different versions (e.g. sandbox at Summer 11 but production at Spring 11).  Where possible, we always look to avoid major deployments to production in the run up to these upgrade windows.

The next meetup is planned for October/November time - I'm looking forward to it already.