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. SaaS is popular in part because applications can be made available without the long deployment cycle typical of on-premise development. The trick is to adapt your configuration management processes to meet SaaS challenges. So a new report can be delivered immediately or a new field can be added to a data entry form on the fly.
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. But as SaaS offerings such as Salesforce.com have matured into full-fledged development platforms, the complexity of applications has grown dramatically. This increases the risk that a minor change could impact critical business processes or break the application. 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. 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.
The Force.com platform, Saleforce.com's custom development platform, is based upon the Model-View-Controller paradigm. 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. This paradigm can be defined as: * Model represents the database structure. As soon as a field is defined or modified it can be queried via SOQL, the Salesforce. Salesforce.com has a built in forms editor for "page layouts" that are associated with data objects.
Com Object Query Language, or SOSL, the Salesforce Object Search Language used for free form text searches. * View represents the user interface. 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. 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. Rules for field validation, workflow and button actions are configured via the setup menu. Force.com development uses practices that should be familiar to most Web developers.
A sandbox can house a full copy of production data, code and configuration, or just configuration. 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. 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. Apex has a built in unit test framework that requires 75% coverage for all Apex code before it can be deployed. A project can be synched to a code repository, allowing check-in and check-out of code.
The Force IDE deploys code from a project to a production org. Ensuring reliability for the enterprise involves: * Limiting which users have a system administrator profile and defining their configuration management responsibilities. * Putting procedures in place to insure that code, configuration and data for production are checked into the code repository and archived (this may require taking manual snap shots of sharing rules, the role hierarchy and so on). * Creating manual or automated installation scripts. * Making sure that there is a plan for backing out production changes if needed. * Deploying to a sandbox for testing and QA. * Repeating the deployment to production. * Validating the deployment in production. How to address audit, security and business continuity upfront Configuration management traditionally looks at production configuration and code as a "baseline," identifies changes that will be released, and incorporates them into a new, auditable baseline once the release is validated. The gotchas Even senior developers can get lost in the weeds trying to figure out how a feature can be, or might have been implemented, in Force.com. Configuration experts and developers run the risk of reinventing the wheel if they do not collaborate closely on solution design. * Force.com deployment tools do not currently support critical items such as data sharing rules, picklist fields on standard data objects, lead and sales processes, and the management role hierarchy. * Apex unit tests are impacted by actual org data, so code that passes unit test requirements in the sandbox may not deploy. Typical "gotchas" include: * With numerous configuration options and powerful programming tools there are many ways to implement the same features.
For example, data queries on objects with more than 100K of data require querying an external ID field. Success is all in the plan Getting configuration management under control is much easier if the development and testing teams are on the same page from day one. Unit tests that pass in a sandbox can fail in production, killing your deployment. While typical build/release cycle looks like this: * Check in code. * Compile code. * Run database scripts and deploy code to test. * Run tests/inspections. * Deploy to pre-production/production. * Validate deployment. SaaS software development platforms such as Salesforce.com require a mix of configuration and custom development that can confuse developers and be difficult to deploy.
The following tasks need to be adapted for Salesforce.com development: * Check in code and configuration from development. * Check in task list for manual changes to the code repository. * Deploy manual code/configuration changes to test. * Run Eclipse/Ant automated deployment to test. * Run tests inspections. * Deploy using same process to pre-production/production. * Validate deployment. This can be addressed by adapting your configuration management processes for SaaS projects. Once you understand how standard programming and configuration management practices apply to a SaaS application it becomes easier to tackle with the traditional approach. Although SaaS offerings are designed to limit the time spent on traditional development, some tweaking is required in order to fully integrate them with enterprise systems. Hamilton is a CRM technical architect at Acumen Solutions, a business and technology consulting firm.
Contact him at ghamilton@acumensolutions.com.