At work, we're starting to talk about overhauling our software application build, deployment, and versioning processes and technologies.
One of the tensions in coming up with organized versioning has to do with the fact that these days, it's considered good practice to push software application code onto end-user-facing servers via your version control system. An alternative approach is to push software application code onto end-user-facing servers some other way, and then separately throw a copy of "the latest server code" into your version control system. In my opinion, it can be pretty tough to decide which of these philosophies to follow when trying to use version control software with Salesforce.
Background: Each copy of Salesforce that a company buys comes with at least one ("production"), and possibly several more ("sandbox"), independent databases. (They're vaguely aware of each other's existence, but live on different servers, don't have any configuration-file interdependencies, etc.) "Sandbox" databases can be destroyed and rebuilt -- empty of data -- in the image of the "production" database (application code included), at the click of a few buttons from the "production" database's web-based administrative UI. New "sandbox" databases can be created the same way.
The back-end configuration files from which each of those databases knows its own definition (schema, application code, user permissions) are in plain text (usually XML, but some Java-like source code files as well) and live on Salesforce's servers along with the data stored in the database.
For each database, there are 3 ways to modify those back-end configuration files:
- Log into the database's web-based administrative UI and point-and-click your way through changes (think of it like modifying an MS Access database).
- In a "production" database, this option is only allowed for schema and user permission changes, not for application code changes.
- In a "sandbox" database, the web-based administrative UI also involves a small IDE for modifying application code. Such code is often moved to a "production" database via option #2 below.
- Log into the web-based UIs of 2 databases related to the same "copy of Salesforce bought by a company" and specify that certain components of one database should be written to the other. (Often used by novices for migrating application code from a "sandbox" database to a "production" database. Known as using "change sets.")
- Upload a fresh copy of a configuration file to the database's SOAP HTTP API endpoint in a packaged "build" ZIP file.
- (Downloading/uploading via the Eclipse "Force.com IDE" plugin or the "ANT Force.com Migration Tool" or Workbench or MavensMate or WelkinSuite are all just tools that take care of the "SOAP" part of option #3 for you.)
Option #3, which involves getting/sending copies of the configuration files to and from Salesforce's servers, is the only option that truly integrates with version control systems. That's because it's the only option that actually involves using copies of the configuration files sitting on a machine that isn't the Salesforce server itself. (Salesforce won't let you make a version control repository out of the database server itself the way some other code-hosting cloud services will.)
Because option #3 can involve version control systems, it plays nicely with the modern software application deployment philosophy of "push configuration files onto end-user-facing servers via your version control system." However, a key rule that everyone has to follow to make this philosophy work seems to be: "Do NOT modify the database's configuration files in any way other than via the version control system. Seriously. Don't. Even if the database will let you. Just don't."
Unfortunately, that's pretty much impossible to enforce with Salesforce. Salesforce advertises how easy it is to use option #1 & option #2. They encourage "clicks, not code" for schema and user permission changes (as well as for some "application" development). In the end, it's unlikely that the database configuration files actually out on Salesforce's servers truly match the copies of those configuration files sitting in your version control system if you're only moving copies in the direction of VCS repository -> database.
If you find that your company is mostly using option #1 and option #2 to modify code in your Salesforce databases, you can still use version control software. Essentially, you use the "get copies of database configuration files" functionality of the database's SOAP HTTP API to download copies of code onto a machine that does host a version control system repository. Do this as often as you want to "checkpoint" the current state of a Salesforce database. Example here.
I've also heard of companies that finagle some sort of hybrid solution: they do what I just suggested with a scheduled tool for everything but configuration files representing "application code."
People who write "application code" are expected to follow "push configuration files onto the end-user-facing server via your version control system" practices.
(From what I understand, they have to be pretty skilled with version control tool branching and merging, as well as efficient XML file editing, to handle the fact that lay-people might concurrently use option #1 & option #2 to modify schemas & user permissions that they also need to modify and were planning to modify via option #3.)
Personally, I think it's also hard to decide how many version control system repositories to spin up:
- One repository for each database in a "copy of Salesforce a company bought"
- One big repository (perhaps with 1 sub-folder per database) for each "copy of Salesforce a company bought"
Novices to Salesforce and Git using the Eclipse "Force.com IDE" plugin to facilitate downloading copies of their databases' configuration files could easily find themselves in the "1 repository per database" approach because version control systems often use a computer's file-system folder as the boundary of a "repository," and default setup with the Eclipse plugin seems to give you one file-system folder per database (not clumped together into any sort of overarching folder representing the "copy of Salesforce a company bought").
- That might actually be rather nice, because then your check-in comments about changes you've made in the various databases are naturally segregated from each other. It might also be easier to use graphical user interface tools to search a repository for a file by its name without seeing a bunch of clutter from other databases if the repository only represents other databases.
- However, you're leaving your colleagues with more repositories to wade through asking themselves, "What's this one for?"
I don't completely understand it yet, but my understanding is that people in "push configuration files onto the end-user-facing server via your version control system" workplaces prefer the "one big repository for each 'copy of Salesforce a company bought'" repository structure.
No comments:
Post a Comment