Did you miss Cloudstock? This first of its kind event brought the top cloud developers and the top cloud technologies together under one roof. If you missed a session, or if you weren’t able to come to Cloudstock, here is your chance to enjoy the event online.

Cloudstock was organized by Salesforce and the event drew a who’s who of cloud technology providers. There were 65+ sessions with a goal, “to bring the top cloud developers and the top cloud technologies together under one roof, to learn from each other, collaborate, innovate, and drive the future of cloud computing.”

The massive scale of the event makes it difficult to watch all the recorded sessions, so I’ve noted my favorite sessions below. Enjoy!

Bringing Services to the Cloud by Heroku

Using Spring as a Cloud App Development Platform by VMware

Run it, Build it, Change it: Open Source in the Cloud by Rackspace

Rapid Cloud Application Development

AWS Feedback Session

Just a quick reminder that the Spring ’11 release of Salesforce is right around the corner. Click here to view the release page for highlights or to download the full release notes or click here to view the release webinar.

My personal favorite improvements are criteria-based sharing which allow administrators to define data-dependent sharing rules with clicks, not code and @Mentions, #Topics and likes in Chatter, which enhances the ability to loop colleagues in and keep track of conversations.

Following my recent series of blogs on continuous integration on the Force.com platform I thought it worthwhile following up with a short slide presentation and actual demo of CI working in the wild. So please view the slide presentation here:

and the demo here:

This is the third instalment of my blog series on continuous integration (CI) with Force.com. If you haven’t done so, you may want to read Streamlining Force.com Projects with CI and An Architectural Overview of Cloud-Based CI. Today I’ll provide an overview of our configuration at Myriad Minds and what’s needed to get all of the components working together in a seamless cloud CI solution.

Configure Bamboo

So to configure our CI process we use Bamboo hosted from a Atlassian JIRA Studio instance. For the global Bamboo configuration we require the following:

• An Amazon Web Services (AWS) account.
• To configure Bamboo with the AWS account access and secret key.
• To configure Bamboo to provision an EC2 instance (Elastic Image Configuration in Bamboo terminology) or supply an AMI ID (An AMI ID identifies a custom preconfigured EC2 image). If you do not specify an AMI ID Bamboo will provision an instance on your behalf that comes preconfigured with the following capabilities:
  • Builder capability
    • ANT
    • Bash
    • Maven 1
    • Maven 2
    • Script
  • and JDK Capabilities
    • JDK 1.5
    • JDK 1.6

For our Force.com builds we are interested in the ANT capability using JDK 1.5 or above. It’s worth noting that other capabilities may be required, dependent on the complexity and scope of the build. If you have custom requirements, you can add them as custom capabilities in the Elastic Image Configuration.

Configure Builds

Now we’re ready to configure a build at the project level by specifying the following:

• Source Repository: The URL to our source code repository, together with any associated credential information. This is the location from which the code is checked out each time a build is triggered. There are a host of options in specifying when to trigger the build and what to include and exclude.
• Builder: we use the ANT builder, as we are using an ANT script for our build.
• Notifications: details who gets notified about the build and the events that trigger notification. There are many options, but the default is to notify all configured users at the completion of every build, regardless of the build’s outcome.

Multiple builds can be configured and associated with multiple Elastic Agents on multiple projects for multiple clients. It’s all very flexible.

Develop

So now we have our project, associated source code repository, EC2 Elastic Image Configuration and project-configured Bamboo build descriptor. But how does it all work together?

1. Developers check out the project from the SVN repository and work locally using Eclipse connected to their own project org provisioned sandbox. Working in individual sandboxes ensures developers do not write over each others code and enables multiple streams of development to run simultaneously. Sandboxes are provisioned on an adhoc basis can be refreshed very simply from an ANT initialisation script.
2. Code is subsequently committed to the SVN repository, the project-configured build detects the commit on the given branch of development and commences a build if a configured Amazon EC2 build agent is available. If no agent is available, the build is queued until one is.
3. Bamboo sends the code to the Elastic Agent, which runs the configured build script. The script contains all the necessary credentials to connect to the appropriate Salesforce build sandbox.
4. The results of the build are communicated back to Bamboo and notifications are sent to the configured recipients.

The diagram below illustrates the sequence of steps for a typical build cycle (click to enlarge).

Note that it’s feasible to replace the Bamboo and SVN server components in the above diagram whilst still using the same build scripts to run the process. This is useful if you want to leverage your own internal infrastructure for build management.

In summary, cloud CI works and works well. It’s an ideal approach for Force.com projects that use Apex classes, Apex triggers and Visualforce, providing a range of benefits. It encourages developers to write better unit tests. It provides comfort when making changes to the code base. It resolves the challenge of Force.com not compiling code against the entire code base when deploying to sandboxes. It enables geographically disperse developers to collaborate on a project.

Watch this space for more articles – this is a big topic.

We’re back on the topic of continuous integration (CI).

After my last post about the importance of CI and how it relates to Force.com projects, I received some positive feedback, mostly from people asking “That’s great, but how?”. To answer that question, let me first outline the tools we use to implement CI here at Myriad Minds, then explain a little about how they work together.

Our CI implementation uses Atlassian’s JIRA Studio as our preferred platform for project delivery and development. JIRA Studio includes Confluence for documentation and collaboration, Subversion for source control, JIRA for issue management and Bamboo (actually called Elastic Bamboo in a hosted JIRA Studio instance) as the continuous integration (CI) server. Elastic Bamboo utilises Amazon Web Service’s (AWS) Elastic Compute platform (EC2) for compute resources, which allows seamless scalability for any build’s individual resource requirements. This architecture is equally applicable for both client and internal projects.

The following diagram is a high level illustration of our continuous integration architecture. (Click to enlarge)

As the diagram illustrates, code is developed and deployed against a developer-assigned Salesforce Sandbox and subsequently committed to Subversion. Bamboo polls Subversion for changes based on trigger parameters configured when defining the build configuration. Once a build is triggered, Bamboo determines if a valid “elastic agent” is available. If so, it passes the code and build script to the elastic agent to run against the Force.com build Sandbox (as specified in the build script). Upon completion of the build, Bamboo will notify configured recipients of the build’s status. In the event that no elastic agent is available, the build is queued until one is or can be configured to timeout after a given period.

Benefits

• Cloud based configuration and management – can be managed from anywhere the internet can be accessed.
• As the build resource requirements change our infrastructure automatically scales to meet demand.
• No on-premise infrastructure is required, though it’s possible to replace both Subversion and Elastic Bamboo with on-premise alternatives.
• Pay-as-you-go for only the tools you need.
• Security and access is managed in JIRA Studio so developers can collaborate from across the globe – great for development teams spread across disparate locations.
• Tightly integrated with JIRA issue tracking for build reporting and metrics.

This quote succinctly summarises continuous integration (CI). But why is it so important, and how can it benefit your Force.com project?

CI resolves dependency issues

Each time code is committed to a source control repository, it is built and unit tested against the entire code base, ensuring developers are mindful that their commits can and often do cause existing tests to fail. CI can pick up dependency issues at build time – useful for local developer build processes where the IDE may not check issues such as module dependency and compilation.

This is particularly important in a Force.com build environment where code is not compiled or tested when saved to the Salesforce server. Indeed, without a continuous build environment, compilation and unit test failures are commonplace and seldom identified until the entire suite of tests are manually executed.

CI aids the development of better unit tests

Well written unit tests should cover every facet of the entity being tested, be that a trigger, class or component comprising multiple artefacts. The more often that tests are run, the more assured we can be about the stability of our code base. CI ensures that tests are run frequently giving real time alerting on test failures so that they may be resolved early.

CI represents a paradigm shift for many Force.com developers who come from less disciplined development backgrounds. Unit tests should never be simply about ensuring there is adequate code coverage; they must thoroughly test the code including boundary and exception testing. This in turn promotes a more modular approach to software design where tried and tested patterns and techniques can be used to create properly testable, reusable component services.

This article provides great insight into writing Apex unit tests for the Force.com platform. It’s worth noting, however, that the art of writing good unit tests is universal regardless of the deployment platform.

CI allows for test metrics and reporting

Continuous integration servers can be configured to provide test metrics and reporting. It’s possible to view the build history over time for a given branch of development. This can be used to pin-point problem areas and use that information to improve the build approach. At Myriad Minds, using our CI process leveraging  SVN and Bamboo running from a hosted Altassian Jira Studio instance, we rely on key metrics such as Top 10 Most Failing Tests, Top 10 Longest to Fix Tests and Top 10 Longest Running Tests.

Test metrics are useful in a Force.com development project to discover which components are untested or lacking fully integrated tests. We can also target repeatedly failing tests and determine the cause of failure, allowing us to efficiently direct our refactoring efforts. We can assess the unit test coverage and the quality and coverage of commentary. We can even extend our tool in new and imaginative ways to provide metrics we might never have considered.

CI provides accountability

Continuous integration provides visibility into the development teams day-to-day activities, making developers accountable for committing good quality, fully tested code. A CI approach quickly identifies the stars in your development team and, conversely, those developers who might need closer mentoring. CI sharpens the craft of both developer individuals and the team as a whole.

References:

• Martin Fowler is an author and international speaker on software development, specialising in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming.
• How to write good unit tests – salesforce.com’s Developer Force wiki.

There are several exciting new features in the Winter ’11 update. Below are my 10 favorite features.

1.  Quotes Template Editor: easily customize quote templates with just a few clicks.
2.  Drag-and-Drop Dashboards: quickly chart your performance with role-based dashboards.
3.  Dynamic SLA Milestones: facilitate complex support processes by allowing administrators to choose when milestones start using custom start time fields.
4.  URL Redirects: maintain search engine ranking by redirecting visitors to content when links change.
5.  Attach Files to Events & Tasks: Straight forward, but much needed.
6.  Chatter Analytics: create reports and dashboards showing how your company uses Chatter
7.  Chatter Search: easily search across files, feeds, comments, etc.
8.  Chatter mobile for iPhone and iPad: experience the power of chatter on the world’s most exciting tablet – the iPad from Apple.
9.  Chatter Desktop: Stay connected and be instantly updated of important activity within your Chatter feed.
10. Chatter for custom apps: provide a feed for records of custom apps.

For more details, download the Winter ’11 release notes or if you’d rather watch a video, view the Winter ‘11 webinar.

Scheduled Data Export is a rarely talked about feature that may make you a data savior one day.

Data Export lets you prepare a copy of all your Salesforce data. You can generate backup files manually once every six days or schedule them to generate automatically at weekly or monthly intervals. When an export is ready for download you will receive an email containing a link that allows you to download the file(s).

Below are the directions to schedule a backup.

1) Click Setup | Data Management | Data Export and Export Now or Schedule Export. The Export Now option prepares your files for export immediately. This option is only available if a week has passed since your last export. The Schedule Export option allows you to schedule the export process for weekly or monthly intervals.

2) Select the desired encoding for your export file.

3) Select Include attachments… if you want your export data to include attachments.

4) Select Replace carriage returns with spaces if you want your export files to have spaces instead of carriage returns or line breaks. This may be useful if you plan to use your export files for importing or other integrations.

5) If you are scheduling your export, select the frequency, start and end dates, and time of day for your scheduled export.

6) Select the types of data to include in your export. If desired, you can include all data in your export file. We recommend that you include all data if you are not familiar with the terminology used for some of the types of data.

I’ve personally seen this feature save many companies time, money and embarrassment, so setup this free feature today.

I find myself discussing user adoption with clients, prospects and the CRM user community more and more often. The standard advice on this topic is often centred on broad concepts such as ensuring management buy-in, engaging users and implementing change management. These are worthy (if slightly bland) recommendations, but how about some more specific suggestions?

Here are 4 tangible tips that are certain to drive CRM user adoption in your business. (With thanks to Ingrid Elgar of Articulate for her recent contribution on this topic at the Sydney Salesforce User Group):

1. Get your KPI metrics out of Excel and into your CRM: The message from your management team must be that staff performance will be measured on metrics that are in the CRM, not hidden away in a management-eyes-only spreadsheet. If the sales team has a target of 50 deals for the month, then show that number in a big, colourful dashboard component as soon as a sales user logs in. If marketing must hit a 25% lead conversion rate this quarter, then let’s see a funnel graph displaying that number front and centre in the CRM.
2. Close the visibility gap between sales targets and actuals: I see this time and time again. Sales guys can view their deal targets, but the actuals to measure against them are held somewhere else. Too often the opportunity pipeline is in the CRM, but the financials on won deals are in the billing system, and the sales team can’t compare the two until the end of the month. There is no greater motivator for a salesperson than to be able to look at their 6-month pipeline and know that it’s worth $173,465.89; or to see clearly that they’ve achieved $35,650 of their $50,000 sales target for the month. Better still, with a little effort you can calculate sales commissions in your CRM in real time, such that a salesperson knows that closing that killer deal before Christmas is worth $1,275 to their pay packet in January. This may take a little development or integration to pull off, but the impact is massive.
3. Run your team through a performance dashboard: This one’s easy, but too often its value is undermined by indecisiveness and management tinkering. Keep it very simple and just do this:
   • Agree a performance dashboard that contains your key metrics.
   • Announce it at your 10am Tuesday morning sales/marketing/customer service team meeting (I hate Monday mornings, so Tuesday morning it is).
   • Have a scheduled process that emails the dashboard to everyone for 9am every Tuesday morning, for discussion at the meeting.
   • Don’t change the dashboard. For a while, at least. No-one will trust the score if the goalposts keep moving. When the dashboard does need refinement, don’t just tinker with it. Follow the first three steps again methodically.
4. Streamline the user experience: In most offices, management look to ensure each staff member is comfortable. An ergonomic chair, an eye-height low-glare monitor, plenty of natural light … we look to create a pleasant work environment. But then we provide a CRM (where users spend hours each day) where creating a sales opportunity for a new prospect is an 11 step process involving 7 screens, 43 clicks and the customer’s name typed 3 times. It’s an incongruous situation. Instead, take the budget allocated for the new eggplant & cerise paint scheme and spend it on customising the day-to-day user experience of your CRM. Consider three key improvements:
   • Reduce clicks: create shortcuts and rationalise screen layouts. For example, allow a salesperson to create an account, contact, opportunity and task record all on one screen, with one Save at the end.
   • Automate repetitive tasks: if it’s repetitive and manual, then you can be sure it’s annoying and error-prone. Automating repetitive tasks shows that you value your staff to do the work that machines can’t. Email confirmations, status updates and data exports are prime candidates for automation.
   • Make it fun: For the social networking generation, leading-edge technology is actually fun to use. Steal design tips from the web and from devices like the iPhone, that is, the technology people use by choice every day. If you can make your CRM approach a Facebook level of interactivity, your staff will actually want to use it. Be creative.