Even experienced developers can run into problems developing and deploying custom applications for software-as-a-service platforms because SaaS vendors don't always embrace the accepted corporate processes for build, test and release. The trick is to adapt your configuration management processes to meet SaaS challenges.
SaaS is popular in part because applications can be made available without the long deployment cycle typical of on-premise development. So a new report can be delivered immediately or a new field can be added to a data entry form on the fly.
But as SaaS offerings such as Salesforce.com have matured into full-fledged development platforms, the complexity of applications has grown dramatically. A salesforce.com application may have features such as real-time Web service integration, automated e-mail and Web feeds, and batch integration to operational systems. This increases the risk that a minor change could impact critical business processes or break the application.
It is often challenging to apply best practices for configuration management in SaaS environments because:
* The application may be supported by business, not IT.
* SaaS administrators may not be familiar with configuration and release management practices.
* SaaS deployment tools are still maturing.
* Deploying an application often requires both manual and automated steps.
* SaaS integrations require synching releases with legacy systems.
* Code, configuration, deployment scripts and manual checklists all need to be checked into the source code repository.
Consider the development of a Salesforce.com application from a traditional developer point of view, with the goal being to manage development in the most controlled fashion to ensure reliability.
The Force.com platform, Saleforce.com's custom development platform, is based upon the Model-View-Controller paradigm. This paradigm can be defined as:
* Model represents the database structure. This is configured via the salesforce.com setup menu that allows administrators to add custom fields to standard CRM data objects, like leads and accounts, or create new data objects with their own custom fields. As soon as a field is defined or modified it can be queried via SOQL, the Salesforce.Com Object Query Language, or SOSL, the Salesforce Object Search Language used for free form text searches.
* View represents the user interface. Salesforce.com has a built in forms editor for "page layouts" that are associated with data objects. Pages can also be developed in Visualforce, salesforce.com's markup language that is tightly integrated with Apex code, Force.com's programming language that is based on Java.
* Controller represents business and application logic. Rules for field validation, workflow and button actions are configured via the setup menu. Custom business logic is developed as Apex code associated with triggers, Salesforce.com's version of stored procedures, Visualforce controllers, or as shared class libraries.
Force.com development uses practices that should be familiar to most Web developers. Salesforce.com allows copying the production environment or "org" to a "sandbox" just as you would copy the production data model and code to a development server. A sandbox can house a full copy of production data, code and configuration, or just configuration.
Development is done using the Force.com integrated development environment (IDE), an add-in for Eclipse that lets developers create a project linked to a development org, production org or sandbox. A project can be synched to a code repository, allowing check-in and check-out of code.
Apex has a built in unit test framework that requires 75 per cent coverage for all Apex code before it can be deployed. The Force IDE deploys code from a project to a production org.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.