10

Development Life Cycle and Deployment Planning

In this chapter, you will continue learning about the Salesforce-specific knowledge areas a CTA must master. The development life cycle and deployment planning are part of the sixth domain out of seven. You will learn the required knowledge and then complete a hands-on exercise using a small hypothetical scenario for each domain.

In the previous chapters, you covered several topics that are required to develop a secure and scalable enterprise solution using the Salesforce Platform. In this chapter, you will go through the considerations, capabilities, concepts, techniques, and tools required to set up an enterprise development environment.

Enterprises want to ensure they are getting the most out of their Salesforce investment. This cannot be achieved without the right level of governance, which supports and guides development activities throughout the program. Project/program governance should ensure the developed solution meets the business requirements and is easy to maintain, scalable, and bug free and can perform well.

As a CTA, you are expected to be the guide throughout this process. You should be able to help your client establish the right governing body and guide the development teams to put together the development and release process. This will ensure Salesforce features are delivered bug free, on time, and within budget.

There is usually a whole section full of requirements dedicated to this domain in full review board scenarios. This domain has a well-defined scope, which means that the challenge typically lies in the depth of the knowledge required. In this chapter, you are going to cover the following main topics:

• Understanding the roles of a Salesforce development life cycle and deployment architect
• Introducing the development life cycle and deploying a small hypothetical scenario – Model Furniture
• Designing the project environment and release strategy

Understanding the Roles of a Salesforce Development Life Cycle and Deployment Architect

Development life cycle and deployment architects are usually hands-on, technically capable professionals who design and implement a software development environment, including its release management processes and tools. They identify and mitigate project risks and work with other professionals to define an overall testing strategy that addresses quality concerns.

These architects also actively participate in structuring a governance body that ensures the best technical solution is chosen for a given business challenge.

Note

According to Salesforce’s online documentation, a CTA candidate should be able to meet a specific set of objectives, all of which can be found at the following link: https://packt.link/UskVD.

By the end of this chapter, you should be able to do the following:

• Identify project risks and develop mitigation strategies
• Identify the impact of development methodologies on workstreams
• Recommend test strategies to mitigate project risks
• Recommend the right project governance to support technical decision-making
• Craft the right environment management strategy
• Describe the value of continuous integration (CI) tools and source control in release management

Now, it’s time to have a closer look at each of these objectives.

Identify Project Risks and Develop Mitigation Strategies

The review board scenario is designed to represent a real-world use case. In real projects, you will encounter many challenges and risks. Some are related to the platform itself, while others are related to other systems, solutions, or parallel projects.

You are expected to identify these risks and develop a set of mitigation strategies to address them. The risks could be related, but not limited to, the following:

• Conflicting release cycles
• Conflicting processes
• Low adoption and high resistance

Next, you will go through each of these risks in detail.

Conflicting Release Cycles

You could have multiple projects running in parallel on the Salesforce Platform or on another platform related to/integrated with Salesforce. It is common to get conflicts when more than one project/platform has a different release cycle, mainly due to incompatibilities between the versions of the released solutions. You can typically solve this by proposing a combination of the following:

• Multi-layered environment strategy: In this strategy, functionalities are developed in low-level environments and promoted to high-level environments only after passing certain tests and meeting pre-defined quality measures. This allows you to test the functionalities and detect any conflicts at an early stage. The testing process usually includes validating cross-system functionalities as part of what is known as integrated testing.
• Governance body: Governance aims to introduce processes and regulations to resolve and prevent conflicts. A governance body is an organizational structure that includes business and technical members from all relevant teams/projects/streams. This will ensure that functionalities developed by one team are known and approved by the other teams.
• Lively release cycle: Introducing processes, mechanisms, and tools to ensure that all the different streams use the latest code base significantly reduces the chances of conflicts.

More details on each of these strategies are included later in the Recommend the Right Project Governance to Support Technical Decision-Making and Craft the Right Environment Management Strategy sections. Next, you will explore the second most common risk you might encounter while designing your development life cycle and deployment strategy.

Conflicting Processes

One of the key challenges for multi-regional/multi-national projects is the lack of discipline in every region’s business processes. Many enterprises will be looking to get some sort of unification/standardization across these processes. But this is not an easy task, and you usually address it using a combination of the following:

• Using the right org strategy: You covered this topic in Chapter 5, Developing a Scalable System Architecture. Selecting the right org strategy is the first step in providing the right balance between standardization and autonomy. Sometimes, the value of having more than one business unit operating in the same org is offset by the technical challenges that it could lead to, such as interdependencies and complex stakeholder management.
• Using a governance body: This is about creating an organizational structure that includes business and technical members from most, if not all, of the involved regions/countries/business units. This governance body can help harmonize the requirements gathered from all regions, which enables you to design the right solution to meet everyone’s needs.
• Using the right delivery methodology: A modern delivery methodology embraces change, allows prototyping, and keeps the client close to the delivery team. This will help you set up the right expectations and ease any resistance.

You will delve more into the second and third points in the Recommend the Right Project Governance to Support Technical Decision-Making section. Next, you will explore the third most common risk you might encounter while designing your development life cycle and deployment strategy.

Low Adoption and High Resistance

This is a common challenge for any new solution or technology introduced to an enterprise. People are often hesitant to accept things that they do not know by nature. Some users might find it difficult to leave their comfort zone and use a new solution or a completely new platform. Such a challenge requires a comprehensive change management process. This is not something a Salesforce Architect is expected to lead. However, you are expected to be familiar with some of its principles and the common ways of addressing them, which generally include a combination of the following:

• Comprehensive communication plan: A comprehensive communication plan that covers the phases before, during, and after the project. It’s accompanied by a solid training program.
• Governance body: This organizational structure includes business and technical members and involves technology champions from each department. These champions will act as ambassadors for the project within their own departments/regions. They will share their thoughts, challenges, and requirements during the project. They are included and involved in the shaping of the solution. This will give them the feeling that they own the solution and that they are a part of the team. The champions will then become the go-to experts to support other colleagues and ensure adoption once the project is released.
• Right delivery methodology: This keeps the client and champions close to the delivery team. They will understand the solution while it is being built. Therefore, they will not be surprised by the result. This methodology will give them a chance to rectify things during build time and provide feedback. This ensures that the solution is going to be fit for the needs of the end users.

You will cover the second and third points during this chapter, but the comprehensive communication plan is out of the scope of this book. You are encouraged to read more about it from other sources such as the book Practical Change Management for IT Projects by Emily Carr.

Identify the Impact of Development Methodologies on Workstreams

As a Salesforce CTA, you are expected to have strong knowledge of and experience with the different development methodologies used in IT, particularly Salesforce projects.

There are three main development and delivery methodologies:

• Waterfall: In this model, activities are broken down into sequential phases (although some could happen in parallel). The output of each phase is the input for the next phase. This provides a rigid and strongly controlled delivery model.
• Agile: This model relies on discovering requirements and developing appropriate solutions using collaboration between cross-functional team members and the client. Its principles include embracing change, evolutionary development, early involvement of end users, continuous improvements, and early delivery.

Product development is broken into small incremental iterations, called sprints. Each normally lasts between 1 and 4 weeks and involves a cross-functional team working on planning, defining, designing, developing, testing, and releasing the different features included in each sprint.

• Hybrid: This contains elements of both the waterfall and agile methodologies. It normally includes a pre-game/blueprinting phase at the beginning of the project to define the overall scope and agree on the right-level solution design (the term high-level design is intentionally avoided as it could wrongly indicate that the details are not important at this stage). This is followed by a set of activities derived from the agile methodology, where the functionalities are prioritized, further understood, developed, tested, and delivered using sprints.

It is worth mentioning that the right-level solution design is exactly the level of detail you are expected to provide during the CTA review board. You have seen several examples in the small scenarios you have covered already; this is exactly the level of detail your solution is expected to be at after the blueprinting phase.

The following diagram illustrates the difference between waterfall and agile:

Figure 10.1 – Waterfall and agile delivery methodologies

The following diagram illustrates the hybrid methodology:

Figure 10.2 – Hybrid delivery methodology

The flexible nature of the Salesforce Platform makes it very suitable for the agile methodology as it is easy to introduce changes compared to other platforms. However, in some cases, continuous design changes create a hard-to-maintain solution due to the lack of an early solution vision. This is better addressed in the hybrid methodology. This is the reason why you see an increased number of Salesforce projects delivered using the hybrid methodology.

Recommend Test Strategies to Mitigate Project Risks

Every software solution must pass a rigorous set of tests to ensure quality. You need to be familiar with the different types of tests and the environments that are most suitable to execute each of them.

The following table will help clarify this:

Test type	Purpose	Tools
Unit test	This test is used to check your solution’s building blocks’ validity, such as Apex code and different configurations. This is a must-have test, not only for the enforced Salesforce test coverage but also for the value it provides. It should be considered the first line of defense. Unit tests are executed every time new code is deployed to a particular instance. Please note that this could be used to test configured functionalities, not just code.	Apex test classes
Functional test	This test is used to check the validity of a specific functionality’s behavior based on tailor-made test scenarios and use cases. It can be executed manually or automatically using specific tools. Automating these tests ensures that the exact scenario is executed every time they are needed, such as when new functionality is deployed to an environment.	Manual test scripts and automated testing tools such as Selenium and Provar
Integration test	This test is used to check the validity of the solution and confirm that the overall parts of the solution work together as expected. This includes internal parts (such as code changes from multiple sandboxes) and external parts (such as the integration interfaces with other systems).	Manual test scripts and automated testing tools
User acceptance testing (UAT)	This test is used to check specific UAT scripts/scenarios to ensure that the delivered functionality meets the business requirements. This is usually done side by side with the client.	Manual test scripts
Load test	This test is used to gauge the system’s performance under normal conditions but after loading the environment with a huge dataset. This type of test is particularly crucial for solutions with a potentially large volume of objects.	Manual test scripts and automated testing tools; data loading is done using ETL tools such as Informatica
Performance test	This test is used to gauge (and document) the system’s performance under both normal and edge conditions. You need to raise a case for Salesforce to plan this test. This test is particularly important for solutions with complex setups.	Raise a case with Salesforce
Smoke test	This test is used to ensure the system’s overall stability. It normally validates a set of basic, common, and most frequently used functionalities by running a limited set of tests (typically, this is done in the production environment, but it could take place in other environments as well) for a period of pre-defined time. The results are then monitored. This test is based on a simple test you would execute on a newly bought machine; for example, you turn it on and see whether any smoke comes out of it.	Manual test scripts and automated testing tools

Table 10.1 – Purpose and tools of different test types that ensure quality of software solutions

Note

There are different types of tests you can perform, such as regression tests, security tests, penetration tests, and more. Regression tests usually include a combination of functional tests, integration tests, and smoke tests. Security and penetration tests are beyond the scope of this book.

In the Craft the Right Environment Management Strategy section, you will explore the environments that are most suitable to perform these tests.

Next, you will learn about the governance structure required for your projects.

Recommend the Right Project Governance to Support Technical Decision-Making

Project governance is essential to the success of any project. Suppose that different teams are developing and releasing different features and functionalities. They could overwrite each other’s work, redevelop the same functionalities multiple times, create conflicting functionalities, modify the data model and the sharing model to negatively impact performance or security, and create a difficult system to change and maintain. In short, this could result in total chaos.

Can you imagine an instance where the situation is even more complicated? Imagine multiple Salesforce teams (probably from multiple service implementation partners) developing and releasing a series of functionalities and solutions. These solutions involve other integrated applications. One team is building a series of Apex classes to develop point-to-point integration interfaces. Another is using an integration middleware, and a third team has decided to develop their own versions of these Apex classes because they are unaware of the work of the first team or due to time constraints.

When different teams begin to introduce different processes and bring in disparate ways to use Salesforce (probably to meet the same objectives), this will inevitably create confusion within the organization. Moreover, this will likely result in a lot of duplicate work, which all enterprises should try to avoid in order to maintain an efficient setup.

This is a common challenge not only for complex implementations but even for more straightforward projects. This is exactly why enterprises create a Salesforce Center of Excellence (CoE).

A Salesforce CoE is a central governing body that deals with anything related to Salesforce. The CoE is a unified entity responsible for discussing, evaluating, challenging, and deciding on everything associated with Salesforce. It includes both business and technical members from across the enterprise. The CoE is concerned with topics such as the following:

• Are IT and business aligned?
• Does the delivered solution meet the business requirements?
• Will the project be delivered on time?
• Will the project be delivered to the budget provided?
• Have the necessary compliance considerations been made?
• Does the design adhere to best practices?
• Does the design reuse the enterprise-wide components?
• Does this project have the right governance model?
• Does the CoE have the right people around the table to make decisions?
• Are there any architectural frameworks that have been defined? Code standards? Best practices?
• Is there effective communication between different teams and stakeholders?

The CoE can contain a sub-body that is responsible for challenging and approving every design decision that’s made. This is referred to as the design authority (DA).

The following diagram explains the standard structure of a Salesforce CoE:

Figure 10.3 – Proposed CoE structure

The actual implementation could vary from one client to the other. This is by no means a one-size-fits-all structure. You need to work out the right format for your client. During the review board, you need to come up with a proposal based on the scenario. The preceding diagram is a good place to start.

The DA may have the following structure:

Figure 10.4 – Proposed DA structure

The structure of the DA could also be different from one client to the other.

During the review board, you need to explain the value of a CoE, what roles are involved in it, and what activities and tasks are expected to be accomplished by the group. This all must be done in the context of the scenario and should address the scenario’s challenges.

Craft the Right Environment Management Strategy

You need to understand the different types of environments that are available in the Salesforce Platform/Salesforce Core Cloud. You should propose an environment management plan that includes the right type of environment, explain each environment’s use, and justify the rationale behind the selected environment type.

In organized development environments, the development process contains multiple stages (such as development, QA, UAT, and so on). The activities in each of these stages are accomplished in a different environment. This separation of concerns removes any dependencies and allows other teams to work in parallel. This multi-layered development environment is something very common in Salesforce, mainly because it is easy to create sandboxes.

Monolithic applications typically have three environments (development, testing, and production). In Salesforce, you can create more layers to provide an even more organized development and release cycle. The typical arrangement is development, CI environment (also known as the build environment), QA, staging, and production. Additional layers can be added, depending on the project’s nature, such as integration testing, hotfix, and a dedicated training environment.

The following table can be used to help you select the right combination of environments for each task:

Sandbox type	Developing new features	Testing	Integration testing/performance testing	Staging and UAT
Scratch	Excellent fit	Good (unit test, functional tests, UI automated test)	Not a good fit	Not a good fit
Developer	Excellent fit	Good (unit test, functional tests, UI automated test)	Not a good fit	Not a good fit
Developer pro	Good fit	Excellent fit for feature testing; data storage can be used for limited regression testing	Limited usage for integration testing; not a good fit for performance testing	Not recommended
Partial copy	Ensure that the data subsets are fine to be shared with the developers	Excellent fit for feature testing; data storage can be used for limited regression testing and production debugging (data subset)	Good fit for integration testing (limited data subset); not a good fit for performance testing	Good fit (limited data subset)
Full copy	Unusual; ensure it is fine to share data with the developers	Best used for production debugging	Excellent fit for integration testing; ideal for performance testing (considering that it has the same infrastructure as the production org)	Excellent fit

Table 10.2 – Fitness description of different sandbox types for different tasks

Note

You can find more details about the different sandbox types at the following link: https://packt.link/X5blZ.

The following link contains some information about the capabilities and limitations of the different types of sandboxes: https://packt.link/mEpe5.

The following table can further help you select the right combination of environments for each layer of your environment strategy:

	Scratch	Developer	Developer pro	Partial copy	Full copy
Development	X	X	X	X
CI/build		X	X	X
QA		X	X	X
Integration testing				X	X
Training				X	X
UAT				X	X
Load testing					X
Performance testing					X
Staging					X

Table 10.3 – Fitness description of different sandbox types to strategize the right combination of environments

In the solution for this chapter’s mini scenario, you will find an example of an environmental strategy that utilizes some of the environment types.

Describe the Value of Continuous Integration (CI) Tools and Source Control in Release Management

Understanding the value of these two topics is crucial to passing this domain. This goes beyond knowing the different tools and technologies on the market, as you should be able to explain the value of the concept of CI. The multi-layered development environment structure and the automated release management tools have become so popular to the point that some architects are overlooking the original reason CI was created. During the review board, you are expected to explain these details. You are expected not only to come up with the proposed release management but also to be ready to explain why you are suggesting it, as well as how it will solve its shared challenges.

Now, have a quick look at the details of CI:

• CI activities include continuously and frequently merging the developers’ work into a shared build environment. It is preferable for this to be automated. But what is the value of that?

The value is mainly in preventing conflicts and detecting them as early as possible. Developers work in different environments (except if they use a shared development environment, something you should try to avoid as it makes it difficult to trace the developed functionalities and tie them back to requirements). If they are aware of the changes that have been made by other developers, there will be fewer chances for conflicts.

Merging their work regularly and frequently (some practices recommend doing this multiple times a day) ensures that they are aware of the conflicts they have with others as early as possible. This work is typically merged into a specific source control’s build branch associated with the build environments.

• CI also involves ensuring that the developers are preventing conflicts by working on the latest code base (as much as possible). If the developer is working on a 10-day-old code base, it is very likely that another developer has made significant changes to the platform during that period. The chances of that become much lower if the code base is only a few hours old.

To do that, the developers are expected to fetch the latest code base, which is usually available in the build branch. This could take place in multiple shapes and forms. It could be manual, or automated using a simple script, or even using an automation tool. An alternate approach is to build the entire developer sandbox using the code base, which is available either in the source control branch or in the build environment itself.

Scratch orgs are a good example of the first case, where a new scratch org is created and built using the metadata stored in source control every time a developer delivers a new feature.

Sandbox cloning is a good example of the second case: you can clone the build sandbox to create a new development environment with the latest code base.

You need to understand CI and the rationale behind it. It is recommended that you practice it if possible.

CI comes with its counterpart, continuous delivery (CD). CD is more straightforward; it complements CI and offers help to bridge the gap between development and operation by automating an application’s testing and deployment. Establishing the right multi-layered development environment strategy, selecting the right release management automation tools, and crafting a comprehensive automated test strategy will ensure that you have the right building blocks for CD.

The last element to cover here, which is a crucial part of your CI/CD strategy, is source control. Source control management (SCM) (also known as version control) provides you with the ability to track and manage code changes easily and efficiently. It helps you detect and resolve conflicts, and it provides you with a mechanism to roll back changes to an earlier version if needed. GitHub, Bitbucket, and GitLab are very popular SCM solutions.

The final part you need to know about and include in your release strategy is versioning. Each time you release a set of functionalities to production, they must have a version name/number. The version number has three common parts:

• A major version number, which changes with every major release. This could be a monthly or quarterly release that includes major changes to the solution.
• A minor version number, which changes with every minor release. This could be a weekly or bi-weekly release with noticeable changes to the solution, but the essential functionalities are still working the same way as they were previously.
• A patch version number, which changes every time you introduce a new patch to the solution, such as a hotfix.

For example, version 2.1.3 can be translated into major version 2, minor version 1, and patch version 3.

Some might add a daily release number, but this is only applicable to businesses with a very rapid release cycle.

Now that you are familiar with this domain’s expectations, let’s look at a practical example of using this knowledge to design smooth and scalable development and deployment processes.

Introducing the Development Life Cycle and Deploying a Small Hypothetical Scenario – Modern Furniture

The following scenario describes a challenge with a particular client. The scenario has been designed to focus on challenges related to the development life cycle and its deployment. This is one of the domains that depends the least on other domains. Despite this, it is vital for the success of any project in real life.

Go through the scenario to build an understanding of the required solution. Then, go through the requirements one by one and try to solve them yourself, then compare your solution with the suggested one.

Make yourself familiar with the diagrams provided earlier (Figure 10.1, Figure 10.2, Figure 10.3, and Figure 10.4) in this chapter. Many of them can be reused with little or no changes. Learning them off by heart could save you a lot of valuable time while you are creating your review board’s solution. Without further ado, let’s proceed to the scenario.

Scenario

Modern Furniture (MF) is a large furniture retailer operating in the United States. It has been using Salesforce Sales Cloud and Service Cloud for about 5 years. You, as their trusted consultant, have been requested to review their environments, particularly the release process. They are open to suggestions and would like to become more agile and quick to respond to market demands.

During the last 4 years, their release strategy utilized Visual Studio Code (VSC) as an IDE and a tool to deploy metadata between their different sandboxes and their production environment. From time to time, they also used change sets, although the developers favor VSC.

Current Situation

MF has the current situation:

• They are mainly organized into two teams. The Sales Cloud team releases a new version of their solution every month, while the Service Cloud team does that every 3 months.
• Half of each team consists of code developers. The other half are either administrators or point-and-click developers.
• Currently, each developer (code or point-and-click) uses their own sandbox.
• A senior executive in MF is a strong supporter of innovation. They often need to create a separate development environment for their team to carry out different initiatives.

MF investigates their issues internally and defines a set of requirements.

Requirements

MF has been struggling with many issues recently. Some of them can be traced back to their governance model and release strategy. They shared the following requirements:

• In general, there is a lack of auditable records of the functionalities that have been released in each version.
• Both development teams reported challenges during deployment, such as the inability to predict the result. On many occasions, a piece of functionality would work perfectly in the sandbox but would fail to be deployed.
• The current process is creating several conflicts between the two development teams. On many occasions, they have overwritten each other’s work.
• The reported number of bugs in production is high, especially after deployments. This seems to be on the rise.
• The QA team is overwhelmed with tasks. They cannot keep up with the developments and are consistently leaking untested bugs. The QA team reports that 90% of their test scripts are manual.
• The last deployment took more than 5 hours. The actual deployment time was estimated to be less than 30 minutes. The delay was traced back to the significant number of failures experienced before managing to deploy successfully.
• Currently, there have been a lot of challenges regarding the existing environment setup. The teams are unsure whether they should continue using a developer sandbox for each developer or have each team share a single sandbox.

MF is looking for your help to rearchitect its current strategy to allow them to be more agile and responsive to its business needs.

Designing the Project Environment and Release Strategy

Give yourself time to quickly skim through the scenario, understand the big picture, and develop some initial thoughts about the solution. This is a must-do step for every scenario. In this scenario, you will find some requirements that are related to each other and can be clubbed together.

Understanding the Current Situation

MF is using two different clouds. The scenario did not specify that both these products are in the same environment, but considering the difficulties in release management, it is fair to assume so. Note that this challenge is not likely to appear in a multi-org setup.

MF used VSC and change sets to deploy metadata between environments. What does that information tell us?

It probably indicates that no SCM is included, which means that changes cannot be tracked and tied back to a requirement. Moreover, that could indicate that the environments are likely out of sync.

Out-of-sync environments could become a real challenge during deployments. One environment might have built some functionalities depending on a specific system state and designed all its tests based on that. While releasing to production, the system might be in a different state, which will cause some tests to fail and some functionalities to behave irregularly.

You also learned that there are two main teams working for PFM and that they operate in different release cycles. This usually occurs in parallel projects but could be a significant risk for the platform in the short and long term.

You also learned that each developer is using a separate sandbox. Now, use all this information to build your landscape architecture and current development life cycle diagram.

Your landscape architecture may look as follows:

Figure 10.5 – Landscape architecture

On the other hand, your development life cycle diagram may look as follows:

Figure 10.6 – Development life cycle diagram – first draft

Now that you understand the current situation, move on and look at the shared requirements.

Diving into the Shared Requirements

Now, go through the requirements shared by MF, craft a proposed solution for each requirement, and update your diagrams accordingly to help with the presentation. Start with the first requirement, which begins with the following:

In general, there is a lack of auditable records of the functionalities that have been released in each version.

This requirement should be an assertion of your previous expectations. If the deployments are taking place using change sets and the IDE, they likely lack an auditable record. This can be overcome with a very high level of discipline, of course, but from my experience, that is nearly impossible to achieve.

There is a solution, and it has been battle-tested for years in custom software development rather than with Salesforce. That solution is SCM. You came across the concept and value of SCM earlier in this chapter. Your proposed solution could be as follows:

To resolve this issue, I propose using a source control management solution to track the changes in all trackable metadata in Salesforce. The SCM will give a full history of all developed features.

I propose using a tool such as GitHub. We can even tie back the SCM changes to the related user stories in MF’s project management tool, such as Jira.

This will give us visibility of any developed features and will allow us to create a release note containing all the new features of a particular release. The SCM will be part of our overall development and release strategy, which will be explained next.

Note the relationship between this requirement and the next: the lack of auditable records and the reported code conflicts can both be addressed using the right release management process and tools. You need to go through all these requirements to come up with a comprehensive solution that is fit for the given business challenge rather than something generic. You might decide to split up your answer during the presentation and map it to each requirement. However, the proposed solution should consider all of them.

Also, note that you need to explain the value of SCM shortly and concisely. Remember that the audience is supposed to be CXOs from the client company. They know what SCM is, but you need to explain the value it adds to your solution.

Now, you can move on to the next requirement:

Both development teams reported challenges during deployment, such as the inability to predict the result.

This is another thing you could predict, even without MF reporting it. It is a common challenge when parallel teams are developing new features in silos. They have no idea what the other team is building, and even if they do, they have no mechanism to ensure that it would not conflict with something else they are developing.

This challenge is the key reason why two of the concepts you encountered earlier in this chapter were created: multi-layered development environments and CI.

You need to utilize your proposed development life cycle diagram to explain the proposed solution. Your proposed solution could be as follows:

To address this requirement, I propose an environment strategy where we utilize additional environments and SCM to detect conflicting functionalities earlier. In my development life cycle diagram, you can see that the development efforts would continue to take place in the developer sandboxes. Once the developer is done building and testing a feature on their local sandbox, they will raise a pull request to merge the new/modified metadata with the CI branch.

The SCM will detect whether there are any code conflicts that need to be resolved. And if any exist, the developer will be requested to fix them. When the pull request is approved, an attempt to deploy these changes to the CI environment will take place, which would also run all unit tests. If any of the unit tests are broken, the deployment will fail, and the developer will be requested to resolve the issue. The CI environment will always have the latest code base from both teams, which means that conflicts can be detected much earlier in the release cycle.

Once the changes have been deployed to the CI environment, they can then be promoted to higher environments, as per the agreed time and procedures.

Your proposed development life cycle diagram may look as follows:

Figure 10.7 – Development life cycle diagram – final

This pretty much answers this requirement. Note that this diagram is almost complete, even at this stage. This diagram is one of those that you would likely build in one go once you have gone through all the related requirements, unlike other diagrams, which you would progressively develop.

Now, continue to the next requirement and build your end-to-end development and release management solution:

The current process is creating several conflicts between the two development teams.

Your proposed solution could be as follows:

As mentioned earlier, the CI branch and environment will contain the latest code base from both teams. This means that any conflicts are going to be detected and resolved at an early stage. However, to ensure the developers do not create conflicting requirements in the first place, I propose introducing a mechanism to refresh the developer’s sandbox once a new feature is merged into the CI environment. This will be accomplished by retrieving the latest code base from the CI branch after merging and resolving conflicts and using it to refresh the developer’s sandbox. The refresh process can either be automated or introduced as a manual step that the developer is expected to complete.

In short, the developer will get the latest code base from the CI branch and deploy it to their own environments before they start working on any new requirement. They will need to resolve any merge issues. By the end of this process, they will be developing the new feature on the latest code base, which will reduce the potential of overwriting someone else’s code.

We can also utilize scratch orgs instead of sandboxes for developers to make the process even more streamlined. However, we need to try this out first and ensure that the time required to create a new scratch org is not becoming a hurdle for the overall process.

Again, remember that it is not enough to know what the ideal setup should be. This can be easily gathered from different online resources. You should also know why it has been designed like that in the first place and defend the rationale behind it.

The reported number of bugs in production is high, especially after deployments.

This requirement could be addressed by introducing a more structured testing mechanism. The multi-layered development environment that you proposed should automatically address part of that as it reduces the number of errors created by code conflicts. But to further improve this process, you can utilize automated testing tools and ensure that the unit tests are used properly. Your proposed solution could be as follows:

The newly proposed multi-layered environment strategy should help to address some of these issues. On top of this, I propose using an automated testing tool such as Provar. Release management needs to be automated as much as possible. I also propose using a tool such as Copado to manage the entire release cycle. Copado can be configured to automatically start the Provar testing scripts once the code is merged successfully into a particular environment. This will increase the solution’s overall quality and reduce the number of reported issues.

Moreover, the multi-layered environments will ensure that most issues are caught way before they reach production.

In addition to this, I propose utilizing the Apex unit tests to create a business logic-level testing layer that is automatically invoked once a particular functionality is released to an environment. Apex tests will include test methods for positive and negative use cases to ensure that we cover as much logic as possible.

The QA team is overwhelmed with tasks. They cannot keep up with the developments and are consistently leaking untested bugs.

The previously proposed solution addresses most of this. Your proposed solution could be as follows:

The previously proposed solution already addresses this requirement. Provar would allow us to convert many manual tests into automated tests that can be easily and consistently invoked at various stages. This combination of automated scripts, Apex unit tests, and a structured multi-layered development environment approach would ensure that the QA team’s load is eased up.

Now, move on to the next requirement, which starts as follows:

The last deployment took more than 5 hours. The actual deployment time was estimated to be less than 30 minutes.

Again, most of this is addressed by the previous points. Your proposed solution could be as follows:

Using a combination of multi-layered development environments, source control, automated release management, and automated tests should reduce the number of reported issues and help with discovering them earlier. This means that the features released to production have already been thoroughly tested. The entire deployment had taken place at an earlier stage when we moved the new features from the QA to the staging environment. This means there is a very small chance that the deployment to production would fail.

Next, move on to the next and final requirement, which starts as follows:

Currently, there have been a lot of challenges regarding the existing environment setup.

The teams are unsure whether they should continue using a developer sandbox per developer or have each team share a single sandbox.

This is something you addressed in your previously proposed solution, but do not skip any requirements. Make sure you cover everything in your presentation. Your proposed solution could be as follows:

I propose continuing to use a developer sandbox per user. We can also investigate the possibility of using scratch orgs, as we previously mentioned. However, in both cases, I do not see the members of each team sharing a single development org, as this will make it nearly impossible to track all the changes happening and tie them back to a user story or task. This means we lose the desired transparency, which is one of MF’s main requirements.

That concludes this scenario. The diagrams you created earlier (Figure 10.5 and Figure 10.7) are still valid.

Summary

In this chapter, you have dived into the details of the Salesforce development life cycle and deployment domain. You learned what is expected from a CTA to cover and the level of detail. You dissected some key principles, such as DevOps, CI/CD, multi-layered development environments, and SCM. Then, you learned about their importance and their impact on the development and release cycle.

As you might have already noticed, the scope of this domain is limited. The key challenge with such domains is in the depth of knowledge, understanding why some best practices are there and how to implement them.

Then, you tackled a small hypothetical scenario that focused on the development life cycle and deployment, and you provided solutions for it and created some catchy presentation pitches. You developed a development and release diagram that could be easily reused for other scenarios (with minor changes), and you learned how to present this to an audience to capture their attention and provide them with detailed information and rationale behind the proposal.

In the next chapter, you will move on to the seventh and final domain you need to master, which is communication.