With the booming Salesforce economy, today is a great time to jump in to Salesforce Development. In this post, we will provide a broad foundation for approaching Salesforce Development. You will come away from this post with a number of resources that will guide you on your journey. This post is intended for any individual interested in Salesforce Development, but if you’re coming from a previous development role or C.S. foundation you’ll be up and running in no time!
“Whats your stack?” – Most common developer Icebreaker
The Salesforce Platform is the whole enchilada! Salesforce Developers are Full Stack Developers.
When implementing a technical solution you will often find yourself working across the whole stack. Below is a basic list of the Salesforce platform stack that a developer will find themselves working with quite regularly.
Front End – Lightning Web Components, Aura Framework, or Visualforce
Backend – Apex, Triggers, Web Services, REST/SOAP API
Database – Salesforce Objects and Fields
Throughout this post we will also be referencing Trailhead. The Salesforce learning application is a superb resource to get up and running as a Salesforce Developer.
The experience on Trailhead is gamified and a user can earn badges for completing a trail(a collection of concentrated tutorial exercises). The content on Trailhead is continually updated and seasoned developers use Trailheads as a continuing education platform.
As a developer, we are constantly looking to fulfill our curiosity of experiencing a new language or framework. Fortunately, Salesforce Developers write in two of the Most Popular Programming Languages (Kind of Apex ≅ Java).
Apex is a strongly typed object-oriented programming language. It is very similar to Java and C# and a developer with previous experience with an object-oriented language will feel right at home.
One thing that separates Apex from other languages is that it was created to be cloud-first . The language is written and compiled on Salesforce’s multi-tenant cloud architecture and is tailored for data access and data manipulation.
To get started with Apex, head over to the Apex Trail!
To get started with Lightning Web Components and Frontend development on the Salesforce platform, head over to the LWC trail!
Salesforce Objects and Custom Objects are equivalents to a database table in a relational database. Salesforce Fields and Custom Fields are the equivalents to a table’s column.
Depending on the cloud you’re working with, Salesforce will come with a number of Salesforce Objects and fields in the instance. For example, Sales Cloud will come with Account, Contact, and Opportunity.
If the default Salesforce Object doesn’t match your feature or use case, you can always create a new Custom Object. The new object will only have a few default fields and thus you’ll need to add columns/fields to the object to fit your requirements.
Both SOQL and DML are supported directly in Apex, unlike many other development languages that require additional libraries or frameworks to support SQL or database CRUD actions.
To get hands-on experience working with Salesforce Objects and their data, check out this SOQL/DML trail!
Developing in the cloud requires nothing more than your computer and an internet connection. Simply login to your environment, or in Salesforce terms an organization(org), and you can immediately start developing and testing.
Salesforce has a couple of different types of orgs. In this post we’ll stick with the three common types you’ll experience Production org, Sandbox/Developer Org and Scratch orgs.
This is the live data instance where your beautifully designed technical solutions get into the hands of your business’ users. As a developer, I’ll assume you’re familiar with “Production code” or a “Production Deployment.” If you’re using version control, the production org should be in sync with your master branch. (Gitflow branching methodology assumption)
A few interesting details about development and a production instance:
- You cannot write code in your Production Instance.
- Your total code coverage in the org must be above 70%. Your production deployment will fail if this requirement isn’t met.
- It is from your Production instance that you “spin up” additional Sandbox orgs
Looking to write some code? This is where your primary development will take place. You can stand up multiple sandboxes to match your git branching methodology. At Red Argyle, we typically have a Sandbox to match our Dev and Stage branches. You can deploy code and schema changes between Sandboxes and it is highly recommend having a Stage or UAT sandbox to test your features before deploying to production.
Scratch orgs are a recent addition to the Salesforce Developer ecosystem with the release of SFDX. Scratch orgs are source and configuration driven environments that can be provisioned with the Salesforce CLI. This is a great addition for Salesforce development teams that are looking to build out their own Continuous Integration and Continuous Delivery features at their organization.
Stay tuned for our upcoming blog post about our experience with SFDX and Scratch Orgs.
Getting started in Salesforce Development first appears to be a daunting task. Using your previous developer or C.S. fundamentals to relate to the “Salesforce Way” will get a developer a long way. We have provided an initial foundation for breaking down the Salesforce Stack and this guide should hopefully lead toward an intuitive approach for diving in further.
We have referenced Trailhead and the Developer Documentation a number of times throughout this post. These are necessary tools and as you run into issues or questions you’ll inevitably find yourself using the Salesforce StackExchange.