Developing on Force.com
The Force.com PaaS provides an enormous amount of functionality and flexibility, all of which is driven by the underlying metadata architecture.
There are a number of different ways to develop applications on Force.com, ranging from declarative development (click’s, not code) to APEX, which is an object orientated programming language similar to Java.
Depending on your use case you may only need to leverage the declarative development, however for most mid-sized builds the 80 / 20 rule can be applied (80% Click’s / 20% Code).
Regardless of your development, there are number of developer good practices and tools that will help set you up for success. This is especially important if you are developing for a shared org.
This article will outline some of the good practices and tools that I recommend:
Integrated Development Environment (IDE)
An IDE is a software application that provides facilities to programmers for software development. This includes a source code editor, build automation tools, debugger and (if you’re lucky) code completion features.
With Force.com you have two IDE options:
- Eclipse, which can almost be considered the industry standard. It’s cross platform (Windows, Mac, Linux), has a rich community and supports thousands of plugins for many programming languages. Salesforce.com have an Eclipse plugin specifically for Force.com development, which can be downloaded for free from “developer.force.com”. They also have comprehensive reference library for beginners and experienced developers
- MavensMate (my choice) is an open source Force.com IDE developed by Mavens. This is quickly becoming the community standard for Force.com development due to its integration with the popular text editor Sublime Text. Salesforce.com themselves also point people towards MavensMate as an alternative to Eclipse. If you are developing a mid-complexity application (APEX, Visualforce, etc.) I would certainly recommend the use of an IDE.
Source Code Management (SCM)
A common misunderstanding when developing on Force.com is that you don’t need source code management. The reason that I often hear is that “I have no code, it’s all declarative”.
The important thing to remember is that Force.com is a metadata driven architecture, therefore metadata describes the data structures in your environment and the declarative functionality implemented on the platform (e.g. your application).
As a result it’s still import to use source code management for version control, even if it’s just tracking the metadata changes.
Personally I always recommend Git, which is a distributed source code management system with an emphasis on speed and data integrity. There are plenty of Git services available, however the most popular are GitHub and BitBucket. It’s here where we store all of the source code (e.g. metadata) for all of the projects that are developing for Force.com (just remember to make your repositories private).
Continuous Integration (CI)
Continuous integration is the practice of merging all developer code with a shared mainline on a regular cadence. It enables automated testing and reporting on isolated changes in a larger code base, allowing developers to rapidly find and solve defects.
As a result, continuous integration facilitates the process of agile development, where you are constantly testing your code, ensuing that it doesn’t break the build (small and often).
The industry standard for continuous integration is Jenkins, which is an open-source tool. You can host your own Jenkins instance, but I would recommend a cloud-based service such as CloudBees.
Continuous integration will help facilitate the testing process when moving code between environments (DEV, TEST, PRD, etc.)
Development Environments
Every production Force.com environment comes with a suite of development sandboxes. These sandboxes can be created ad-hoc and are a direct replica of production (however do not include any data). Test data will need to be loaded post sandbox creation, either manually or via an integration (e.g. MuleSoft, etc.)
When provisioning sandboxes to development teams I recommend the following approach, which includes three sandboxes:
DEV = Main development environment.
CI = Continues integration merge / build test environment.
TEST = Formal user testing environment.
A traditional development pattern would be…
- All development will occur in the DEV environment, leveraging an IDE (e.g. MavensMate) and source code management (e.g. GitHub).
- The project teams will then build their code (multiple times per day) into the CI environment leveraging continues integration (CloudBees). This will confirm that their development does not break the build.
- Finally, any code positioned for a release to PRD will be moved into the TEST environment (leveraging CloudBees), where formal testing (including UAT) can occur.
This approach ensures the entire development process can be owed and managed by the development team, offering complete autonomy.
Conclusion
In summary, Force.com is an amazingly flexible development PaaS, which is extended further if you include Heroku (I’ll save that for another time).
Hopefully this information is useful and as always, please don’t hesitate to comment below if you have any questions.