This phase of the Salesforce Platform Governance Method focuses on the development lifecycle and deployment of your project’s application and/or configuration.
Overview
The Salesforce platform differs from other SaaS solutions because it provides the means to perform development and testing outside your production environment. Most other SaaS solutions assume you do all your configuration within your production or live environment.
The Salesforce platform provides a “route to live” capability because it offers far more flexibility in terms of configuration than most other Software as a Service (SaaS) solutions on the market. The Salesforce platform is known as a customer relationship management (CRM) platform, but in reality it is more akin to a Platform as a Service (PaaS) solution, as you can develop applications either declaratively or programmatically and deploy them to the Salesforce platform, applications that in theory could have little to do with customers.
With this level of flexibility, Salesforce needed to deliver a robust set of tools and capabilities that allowed their customers to create on the platform without breaking things for their end users.
The Salesforce Platform Governance Method: Phase I
“Project management, specifications, design, programming, testing, installation and training associated with a specific application development project of any size.”
—Gartner1
“Deployment services support the implementation and rollout of new applications or infrastructure. Activities may include hardware or software procurement, configuration, tuning, staging, installation and interoperability testing.”
—Gartner2
Regardless of the size of your company and scale of your development activities, your project should be looking to formalize your development lifecycle. For smaller companies, you may decide to keep things “light” and implement just enough process and formality to be confident that you can deploy something to your end users that is stable and meets their requirements. For the larger implementations, you may have dedicated teams that own their own processes and tooling to facilitate the development lifecycle.
Solution requirements. It is good practice to document the basic requirements of what it is your business wants your project to construct. This helps drive focus into your activities and allows everyone to measure the success of the project, in that you have delivered against all of the requirements that have been documented.
Solution design. At some point you will require your developers or other technical staff to decide how best to deliver the solution requirements, what Salesforce features will be involved, and how you will go about meeting the requirements.
Solution development. Once your project team has decided how they are going to go about delivering the requirements, your development resources can commence with the work to build. This is usually an iterative processes, working through the requirements, using the design until the work is done.
Solution testing. Once all the construction has been completed, you will need resources to test what has been built by your development teams against the requirements that have been documented. Any features that do not meet the requirements are returned to development for further work.
Solution deployment. Once all the testing has completed and everything has been deemed as meeting the requirements and basically works, your project team will want to deploy those changes so that your end users can utilize the new features you have delivered.
Solution training. It may be that your end users require training on the new features that have been developed.
Of course, this is a very simplified view of what really happens during the development of an application or customization on the Salesforce platform, but it provides the foundation of what your governance team is interested in assuring. Your project will no doubt have some level of project management across off of these areas, providing the “when” things will be done.
Your governance team will not be involved in the actual delivery of the areas previously mentioned, but will be looking to confirm that the project team has introduced enough rigor into the development lifecycle to be confident that what is deployed as a result of that work will not bring the entire Salesforce implementation to a standstill. However, if your company is running a number of projects your governance team may need to expand to provide a platform team capability.
The platform team is a small team that is the custodian of the Salesforce platform and assures that all projects adhere to the standards, and that their resulting Salesforce platform changes all work together in harmony with other projects and pre-existing configuration. In smaller organizations, it may be possible that your project team can also take on this role.
The platform team is a key part of any Salesforce platform implementation. It is this team that protects existing projects running within the Salesforce platform when new projects come along. It is unusual for a project to take on the work of checking that other projects’ work is unaffected by their changes, especially when modifying enterprise objects.
Development Lifecycle
Phase I: development lifecycle & deployment - development lifecycle
Govern the development and release of applications on the Salesforce platform
All development work, whether declarative or non-declarative, will take a specific route to your production Salesforce platform. This will involve a few stages to ensure quality is met and standards are adhered to. The route to production effectively forms a significant part of your governance process and if done correctly can aid your governance processes to become more efficient and easier to execute.
Route to the Salesforce production org
Development Environments
Environment | Description |
|---|---|
Development | An environment in which development, either declarative or non-declarative, takes place. A development environment can be personal to a developer or used by a team and is dependent on specific project requirements. |
Unit Testing | An environment in which testing occurs on specific developed units. A unit testing environment can be personal to a developer or used by a team and is dependent on specific project requirements. |
Quality Assurance | An environment in which project/product quality assurance testing is undertaken. This environment can be used to system test, or perform early integration-type testing, where components developed by multiple developers can come together. |
Integration | An environment in which all components internal or external to a project/product come together to make sure everything functions as expected. Within this environment multiple projects may come together to prove that they can co-exist without any conflicts or issues. |
User Acceptance Testing | An environment in which all components are brought together prior to release into the live environment. The user acceptance testing environment is used to test the deployment of components, projects, and products. This environment is the final point at which issues can be captured and rectified and requires all stakeholders to approve. |
Support | An environment in which troubleshooting takes place. Issues in the live environment are not always easy to remedy in situ; therefore, the support environment provides the ideal place for debugging and other support activities. The support environment will be accessed by multiple teams depending on the nature of the problems being investigated. |
Salesforce sandbox types
Scratch Org Limits
Edition | Active Scratch Orgs | Daily Scratch Orgs |
|---|---|---|
Developer Edition or Trial | 3 | 6 |
Enterprise Edition | 40 | 80 |
Unlimited Edition | 100 | 200 |
Performance Edition | 100 | 200 |
Environment Sandbox Types
Environment | Sandbox Type |
|---|---|
Development | Developer / Scratch Org |
Unit Testing | Developer / Developer Pro |
Quality Assurance | Developer Pro / Partial Copy |
Integration | Developer Pro / Partial Copy |
User Acceptance Testing | Partial Copy / Full Copy |
Support | Partial Copy / Full Copy |
Environment responsibilities
As illustrated, the platform team controls four environments, while the other environments remain in the control of the projects or teams that are producing components and applications that are targeted for the production environment, the production environment being any Salesforce instance used to support the business (there could be more than one).
Environment Responsibilities
Environment | Responsibility |
|---|---|
Development | Project Team |
Unit Testing | Project Team |
Quality Assurance | Project Team |
Integration | Platform Team |
User Acceptance Testing | Platform Team |
Support | Platform Team |
It will be the platform team’s responsibility to provision the environments for use by your project teams. Additionally, the platform team will be responsible for the refresh of all environments, which will be driven by your project’s requirements.
Multiple project teams
With multiple project teams working in parallel, the route to production converges at the integration testing environment, which is controlled by the platform team, and it is here that the platform team takes control of the movement of projects into the Salesforce platform’s production environment. It is likely that the project owners will be involved in this process because they will need to “approve” that their application or configuration is functioning correctly within each environment, something that the platform team may not be able to determine without a standardized way of testing each project automatically.
Conceptual continuous integration and continuous deployment solution
Conceptual CI/CD Pipeline Components
Component | Description |
|---|---|
1 | The development environment is basically the sandbox or scratch org that your project’s developer will use daily. Depending on how you want to configure your projects, you may have one sandbox per development, or one sandbox per team of developers. This will very much be driven by the development required and the way your project team wants to work. If you have multiple developers using a single sandbox, it is good practice to have one of those developers be responsible for understanding that code base (i.e., what is it that will be pushed to other environments?). |
2 | Version / Source Control System (VCS / SCS) is the solution to managing the source that your developers are producing within your sandbox. For the Salesforce platform, this will be significantly metadata, which represents changes you have made declaratively. Additionally, however, if your project is developing Apex classes or triggers, then this will also be included. Your VCS / SCS solution will provide a historical view of all your changes based on the code commits your developers make. VCS / SCS solutions allow your developers to revert to previous versions of metadata with ease, but also store multiple releases of your Salesforce platform so that they can always revert to a previous version if things go wrong. |
3 | The automated build engine is used to provide the backbone to your CI/CD pipeline. Typically, a build engine is a scheduling tool that can execute external software and determine outcomes from the results of that execution. In our context, your project can use this for a few purposes; for example: • Automatically attempt to deploy any code committed to the VCS / SCS into a downstream sandbox • Automatically execute test scripts written in a testing tool • Automatically perform Apex code quality analysis using a code analysis tool • Automatically perform quality checks on declarative metadata, such as checking that all fields have a description and help text |
4 | The governance process becomes simpler with the CI/CD pipeline in place because your governance team is looking at the outputs of your automated build engine. Your platform team could automate this also by providing a pass/fail, for example on code quality analysis, which could automatically be fed back to the project team’s developers. However, it is likely that some manual review will be required to focus on reuse and the use of enterprise objects. |
5 | Once the build and governance have completed, you are left with effectively something that is good to be deployed. Your deployment process will take your project’s application or configuration and deploy it into the next logical environment in the pipeline. Failure of the deployment is reported back to the relevant team, which will largely depend on what environment was next in the pipeline. |
6 | Your environment will now be built, either a project environment or a platform team environment, depending on where you are in your release cycle within your pipeline. This environment can now be used to engage the business for verification that the project team has built what was asked of them. |
The conceptual CI/CD pipeline components just described are flattened for simplicity, but you can imagine this pipeline would be operating across all of the environments discussed in Table 10-1, development environments and multiple projects and multiple features that are being developed.
Conceptual CI/CD Pipeline Component Interconnections
Component | Description |
|---|---|
a | Your project developers will be making changes within their development sandboxes, either declaratively using the Salesforce platform’s admin (Setup) tools or using an integrated development environment (IDE), in the case of developing Apex code. An IDE is not a requirement as the developer console is still available within the Salesforce platform; however, an IDE is recommended. Your project developers will more than likely being working on a specific feature, and once they are happy with their work they will want to use the VCS / SCS system to store those changes. |
b | Once your project’s developers have completed their feature development, they will push their metadata and Apex code to the VCS / SCS solution. Typically they will working in a feature branch and will commit their code to this branch and push that branch to your remote VCS / SCS repository. It is that commit and push that could trigger the automated build engine. |
c | The automated build engine is responsible for performing the tasks required to essentially deliver the needs of the project while also delivering against your governance requirements. The build engine will trigger the governance processes, which could also include automated testing, but fundamentally will extract what is required to the downstream processes from the VCS / SCS solution. |
d | A feedback loop that highlights any issues with the downstream processes that the automated build process is controlling, such as governance and deployment. This effectively supports the need to do something about errors and issues that may arise; for example, conflicts in metadata. |
e | The automated build process will trigger your automated governance processes, or perhaps wait for a manual governance check, depending on the maturity of your CI/CD pipeline. Automated checks could be static code analysis for quality or using XPath rules on your metadata to determine whether your developers have given every custom object and field a description. You could also automatically produce documentation about the release from this information if desired to effectively provide a release note. Additionally, if you are managing an object library that captures the custom objects and fields within your Salesforce platform to determine which project owns which configuration, this could also be updated automatically. Governance could also perform automated testing so that your platform team (if the release is targeted for the integration testing environment) can ensure that the project’s release co-exists with the existing Salesforce platform configuration. |
f | Another feedback loop that provides your projects’ development teams with any issues around the governance processes; for example, a list of custom fields that have no description provided. |
g | Once governance has been completed and everything has passed, or acceptable warning have been provided, your automated build engine will attempt a deploy. The deploy component is responsible for performing all the tasks required to deploy the metadata into a Salesforce sandbox or even the production org. |
h | Finally, you should be left with a sandbox or production org that reflects the development lifecycle stage your CI/CD pipeline was delivering. This could be the user acceptance testing environment, for example, and your automated build engine could inform your testing team that their environment has been successfully built and is ready for them to commence testing (automated or otherwise). |
The conceptual CI/CD pipelines touch on the basic principles of a CI/CD pipeline. It is more than likely that your pipeline will have more or less functionality depending on your requirements and levels of automation you wish to achieve within your company. Typically, automating a CI/CD pipeline is a large up front investment for your company, but can make massive difference a few years in the future when you are releasing changes to your business in days rather than months.
Of course, there are a number of tools available to automate the majority of the processes just outlined; the resource base section of this book will highlight those most commonly used.
During the CI/CD discussion, branches were mentioned within the VCS/SCS solution. Branches are independent lines of work that stem from a single central code base. Depending on the VCS/SCS, the main branch may be referred to as the main, master, default, mainline, or trunk. Developers can create their own branches from the main code line and work independently along with it.
Branching enables teams of developers to easily connect with one another inside a single central code base. When a developer creates a branch, the VCS/SCS creates a copy of the code base at that point in time.
Branching Strategy
Branch | Description |
|---|---|
Hot Fix | The breakdown of hot fixes or issues should be controlled within an issue tracker. Issues then become the project team’s central point of contact for that piece of work. Issue branching directly connects those issues with the source code. Each issue is implemented on its own branch, with the name of the issue key included in the branch name. This way it will be easy to identify a particular issue the code implements. With this level of transparency, it is easier to apply focused changes to the main or any longer lasting release branches. Since agile pivots around user stories, task branches sync up well with agile development. Each user story (bug fix) lives within its own branch, making it easy to view the issues in progress and those that are ready for release. |
Develop | The develop branch is used as an area in which your project’s feature branches come together. You may have several development teams working on numerous features that must all ultimately come together into a release. The develop branch provides a convenient place for testing the integration of changes at the project level. |
Feature | The feature branch keeps all the changes for a particular feature intact inside the branch. After the automated or manual tests fully test and validate the feature, the branch is then merged into the main or developer main branch (to support release branching). |
Release | A release is contained entirely within a branch. This means that later in the development cycle, the release manager will create a branch from the main (for instance, a 1.1 development branch). All changes for the 1.1 release must be applied twice: first to the 1.1 developer branch and later to the main code line. Release branching is an important part of supporting versioned releases. A single product may have multiple release branches (e.g., 1.1, 1.5, 2.0) to support sustained development. Changes in previous versions (i.e., 1.1) may have to be merged with later release branches (i.e., 1.5, 2.0); for example, if a bug is found in production that must be fixed immediately. |
Example branching strategy
The figure demonstrates the multiple branches working together. Your branching strategy might be more complicated and will certainly contain more releases and features than this simplified example.
Your governance team is looking to ensure that your project has this in place and is using it. If a pre-existing solution is already in place, this will make life much easier for your project team. If this is not already in place, it is well worth the investment of creating it if you intend to develop more than one project on the Salesforce platform.
Your governance team may have to evangelize an existing CI/CD pipeline to new teams, especially if those teams are made up of Salesforce developers who have not yet embraced a source-driven approach to the Salesforce platform.
Govern the testing strategies and test plan
Your governance team, now identified as needing to manage the Salesforce platform centrally for situations where multiple projects are delivering into the platform, will need to engage the project teams regarding their testing strategies and plan.
In the simplest of implementations, testing is normally carried out by one or two people as they “poke around” in a sandbox into which a developer or app builder has built some changes. This may work perfectly well for very small projects and limited changes targeted for your Salesforce platform. However, in the main you will be looking to have some sort of test strategy in place so that your governance team and by extension your platform team can be confident that every new release of changes to the Salesforce platform will not break the previous release of changes.
With this is mind, your company has two options with regard to a testing strategy. You have the environments defined previously, and your project teams could be engaged to manually test their configuration in every environment before deployment to production is possible. There is an issue with this, however: who will test the pre-existing projects that are already live? Can you ask every project that is already live to come back and retest their application because someone else wants to deploy? This could be a difficult situation to manage. The other approach would be to ask each project team to provide automated test scripts that validate that their project is still fully operational. This would allow regression testing to commence without their involvement. If a failure occurs on a project that has already gone live during a subsequent test trigger by a different project, that project is responsible for solving the issue.
Your governance team will look for assurance that your projects have provided enough validation testing to perform a successful regression testing process for every release into the Salesforce platform.
Your project teams’ tests scripts should be managed just like any other source, using the VCS/SCS solution. Mature organizations can use these test scripts as part of their CI/CD pipeline to perform automated testing as part of the build engine’s responsibility, again aiding the automation of your governance processes.
You will no doubt hit massive resistance to developing automated test scripts if this is not part of your company’s development culture. Mostly, project teams see this as additional work that provides no business benefit. Your governance team might have to help the business understand the benefits, which will probably be easy after the first time their project stops working in production due to a new configuration’s being deployed.
Deployment Techniques and Considerations
Phase I: development lifecycle & deployment - deployment techniques and considerations
Govern the deployment strategy and the platform tools, use cases, limitations, and best practices for environment management and data migration strategy
Your governance team will be looking to the project team to understand how it intends to deploy its application, and what (if any) business impact this will have. In some cases, a significant amount of business change happens alongside a Salesforce implementation, and as such your governance team will want to know that this is well under way to coincide with the deployment of your project team’s application. The last thing anyone wants is a disgruntled business because they have had their legacy systems’ access removed in favor of using the Salesforce platform, which they know little about.
In the previous section, the CI/CD pipeline was discussed; this is a major benefit when it comes to deploying your Salesforce application into the production org. However, not everything is deployable via metadata. Salesforce has a few areas that are still not exported as part of the metadata your project teams have created. However, with every release Salesforce is closing the gap on what is left that requires manual configuration directly within the product org.
Your governance team will be looking to understand if the project is affected by this manual configuration requirement, which Salesforce maintains as its metadata coverage.
Check the Salesforce webpage https://developer.salesforce.com/docs/metadata-coverage/52 for details on what exactly is covered by the metadata API.
Salesforce provides a few tools for deploying metadata into a sandbox or production instance. For the CI/CD pipeline discussed earlier, the assumption would be to use Salesforce DX.
Salesforce DX (SFDX) is a Salesforce product that allows users to develop and manage Salesforce apps throughout the entire platform in a more direct and efficient way. SFDX, used primarily by developers, allows users to have true version control over their metadata. SFDX is a command-line tool that is integrated into IDEs such as Microsoft’s Visual Studio Code.
Alternatively, if your company has not embarked on moving to SFDX, you may be looking to continue to use the ANT migration tool. Or maybe you are still working with change sets through the admin console.
Your governance team will want to standardize the use of a particular set of tools rather than have every project pick its own. Of course, the Salesforce-provided tools generally have no cost as they are part of the platform. However, there are a number of third-party tools that provide the complete CI/CD pipeline tailored specifically for the Salesforce platform.
Where a platform team has been implemented, it will be their role to define the toolset and instructions for use. Additionally, sandboxes must reflect the current state of the Salesforce platform in production. Your project teams will not want to develop against a configuration that is several months out of date. Having a source-driven development methodology puts less reliance on sandbox refresh strategies because a sandbox can be built from the VCS/SCS, which is one of the most powerful aspects of using this approach. However, your governance team will want to validate that your project team has been developing against the latest metadata before the platform team is handed the package for ongoing deployment to the shared environments.
If your project is re-engineering an existing application onto the Salesforce platform, it is likely that there will be a data migration requirement. Data held in the legacy system that is being re-engineered will need to be migrated. This typically takes the form of an extract, transform, and load (ETL) process. Your governance team will be looking to understand how the project has tackled the ETL and what testing has taken place. The project team will need to be ready to discuss the “T” part of their ETL process, because it is the translation of data from your legacy application to the re-engineered application that will be important.
Govern the tools (source control and continuous integration for release management)
Your governance team will be looking to assure the tooling that is being used, especially if this is something that has not been done before. It would not be efficient for every project team to implement its own tooling independent of every other project. Not only would the costs be a lot higher, but your resources would also lose a level of mobility between projects. Additionally, supporting these tools is typically a full-time job for someone, so the more tools you have, the more resources you will need to support them.
A version/source control system (VCS/SCS) to manage project repositories, branching, and source control
A deployment system to manage extracting source from the VCS/SCS and deploying it into a sandbox or production org
A development environment in which Salesforce developers can create the applications your business desires.
Your company can find a solution to all of these with little or no costs. Some will require degrees of manual intervention, while investing more and buying dedicated tools may remove manual intervention and optimize your route to production.
Lastly, your governance team will want to understand the release cadence that is in place. It is not desirable to have multiple projects trying to all go live on the same day. Your governance team will be looking to understand this so that everyone is aware of a release schedule.
Method
Governing the development lifecycle and deployment of applications on the Salesforce platform has two aspects. The first is making sure that a sufficient solution is in place to industrialize the process or release to the production org. In that solution, governance can be implemented that reduces the governance burden in the longer term. The second is the on-going governance required to make sure things are maintained and changes, whether to a project’s application or to the release process, are thought through and sensible.
This phase of the Salesforce Platform Governance Method is probably one of the most complex to implement because it relies upon a desire to create a centralized model for managing environments and the CI/CD pipeline outside of a project. Of course if your business is expecting to have just the one project for the foreseeable future, then this responsibility will lie within that project.
Development Lifecycle
Deployment Techniques and Considerations
Approach
The development lifecycle should be well defined in terms of the environments and tooling and the “route to production” that an application will take before a project starts developing. The purpose of this phase is to have a means of governing the route to production. In the main, this should not change regularly, but it is not unimaginable that additional Salesforce instances may arise within the enterprise, or that external parties are engaged. In these scenarios, the organization will want to determine whether these situations are adhering to the standards.
Additionally, over time, tooling and testing strategies may change, especially as an organization matures in its usage of the Salesforce platform. Therefore, this phase is also used to manage the evolution of the development lifecycle, as well as the tooling and techniques used.
The phase could employ programmatic solutions to governance to implement automated governance, such as code quality, or remain purely as a subjective review. However, there should be standards regarding product selection, such as a development tool change or the use of a configuration management tool, so that a fair and unbiased view can be drawn to determine suitability.
Inputs
Environment strategy
Continuous integration and continuous deployment
Development tooling
Test strategy and test plan
Steps
The steps to govern your development lifecycle and deployment will help the project team deliver to the business consistently. No one likes a failed deployment, especially when the business is all set to receive a new application or a major update to their existing application. This phase is focused on avoiding deployment failures or destabilizing the existing applications already in use.
Ultimately, the goal is for your project teams to consistently deliver their configuration and code into the production Salesforce platform correctly the first time, but also at speed. The ability to rapidly deploy changes to your production Salesforce platform will reduce the scale of the change as smaller changes can be deployed regularly.
Development Lifecycle
- 1.
Govern the development and release of applications on the Salesforce platform.
- 2.
Govern the testing strategies and test plan.
Deployment Techniques and Considerations
- 1.
Govern the deployment strategy and the platform tools, use cases, limitations, and best practices for environment management and data migration strategy.
Outputs
Not Applicable – This phase in the Salesforce Platform Governance Method is not applicable to the project.
Remediate – The governance team requests that the project team remediate its design to accommodate the issues raised during the governance review.
Pass – The governance team has found no issues or concerns with the project team’s proposal and therefore the project has passed this governance phase.
Review – The governance team has found the inputs cannot be objectively measured and therefore a subjective view has been made, which will lead to a discussion with the project team to reach consensus. Although undesirable, this could be a consequence of unclear standards/policies.
Scenario
Govern the deployment strategy and the platform tools, use cases, limitations, and best practices for environment management and data migration strategy
Hanna Snyder, the project architect from our company Bright Sound Guitars, is now at the point where she needs to think about deployment of her application. She has her requirements and the business funding to develop her application, and she’s ready to start her development work, having gotten through a number of the governance phases. Hanna presents to the governance team her ideas around deployment. As Bright Sound Guitars is a small company, it does not have a platform team as part of the governance team, so her project team will take care of things.
Hanna talks through her deployment strategy. She has spoken to her Salesforce administrator, Fenella Owen, about the best approach to deployment to the production Salesforce platform. Fenella has been in the Salesforce ecosystem for many years and has spent a significant portion of that time using the original Salesforce user interface, today referred to as Classic.
Fenella presents to the governance board that she is looking to have one sandbox that all the development takes place in. They have two developers at Bright Sound Guitars, Ranveer Shah and Caitlyn Horton, and they both have separate areas in which they are working so they should not conflict in one sandbox.
Fenella mentions that Ranveer has spoken about Salesforce DX a number of times, but she has not had the time to investigate this tool. Fenella feels that sticking to the traditional change sets will be good enough. Fenella therefore suggests that she will create a change set from the developer sandbox to the production Salesforce platform and deploy that way.
Once a deployment has taken place, she suggests refreshing the sandbox just to make sure it reflects the production Salesforce platform. However, she doubts that will be much of an issue as they are the only development team working on the platform as far as she knows.
The governance team thanks Fenella for her overview. The first point they make is that Bright Sound Guitars has another project that is just starting up, which will deliver a bespoke application for the manufacturing department. With that, the governance team mentions that Hanna’s team will no longer be the only project team looking to deploy to the production Salesforce platform.
As part of the justification to build the new application, the governance team has secured the budget for tooling and resources to construct a CI/CD pipeline, which is going to be a minimum viable product approach, but it does mean that they would like Hanna’s team and Fenella to review their tooling and deployment approach to work alongside the platform team’s CI/CD pipeline implementation.
The governance team mentions that they will be creating a number of processes to automate some of the code checking governance that is part of Phase F of the Salesforce Platform Governance Method. They feel that there are some quick wins that can be implemented with very little effort, especially around code quality analysis, having just invested in the SonarQube product, which has an Apex extension available. Additionally, they will be implementing a number of XPath rules to check that the developers have completed descriptions against all custom fields and objects. Also, they want to implement name-spacing using a prefix on custom objects and fields. They feel this can be easily checked also.
The consequence of this is that the governance team would like Hanna to review her tooling to work toward implementing the standard toolset defined by the platform team, which will include source control.
Hanna is excited that Bright Sound Guitars is taking development on the Salesforce platform to a new level, and wants to return to her project to discuss how they can work with these new tools and the impact of doing so.
Summary
Building a route to production is an investment that is sometimes frowned upon. It does take time and is often seen as not really achieving very much for the business. However, the initial investment becomes very worthwhile once your project teams have made multiple deployments because of business requirement changes or new functionality.
As with any project, it is best to start out with a minimum viable product, tackling perhaps the “quick wins” that your governance team and project teams need.