Pass the Salesforce Salesforce Developer Development-Lifecycle-and-Deployment-Architect Questions and answers with CertsForce

Change Sets are a manual way of deploying metadata components between orgs that are affiliated with the same production org. Change Sets cannot be automated, rolled back, or reused between production Salesforce orgs. Change Sets can be validated before deployment, and they can be used for orgs affiliated with the same production org.

Utilizing a dedicated developer pro sandbox to address critical bugs and release to production is the recommended release management strategy, as it allows the development team to work on the new project without being interrupted by the bug fixes, and also ensures that the bug fixes are deployed to production as soon as possible. Including fixes for critical bugs in the ongoing development sandboxes is not recommended, as it may delay the release of the bug fixes and also introduce conflicts with the new code. Keeping teams separate until the end of the project and creating a full copy sandbox to merge their work then is not recommended, as it may create a lot of merge conflicts and integration issues. Addressing critical bugs in the development sandboxes and pushing those changes to production separately is not recommended, as it may create inconsistencies between the development and production environments.

Three areas that should be tested as part of data migration are: data transformation against source system, contact association with correct account, and account and lead ownership. These areas can help ensure that the data is migrated correctly and accurately, and that the relationships and ownership are preserved. Lead assignment is not an area that should be tested as part of data migration, as it is a business process that is triggered after the data is migrated. Page layout assignments is also not an area that should be tested as part of data migration, as it is a configuration setting that is independent of the data. See Data Migration for more details.

Minor and Major releases should use the same Full copy sandbox for UAT, as this will ensure that the testing environment is consistent and has the same data and configuration as the production org.

Creating design standards focused on integration and providing training to all teams is the best way to address the challenges of having various integration patterns and a lack of common understanding of the integration landscape. Design standards can help to establish consistent and best practices for integrating Salesforce with other systems, such as choosing the appropriate integration style, pattern, tool, and protocol. Training can help to educate and align the teams on the design standards and the integration architecture.

Minor changes should be thoroughly documented and follow some type of standard cadence, as this can help maintain the audit trail and visibility of the changes. All changes should still be tested, even if they are minor, as they can have unexpected impacts on other parts of the system or introduce bugs or security issues. Downstream environments will not be automatically updated when production changes are made, so it is important to have a strategy to keep them in sync and avoid conflicts or overwrites. Minor changes do not need to be documented and can be made at any time is a wrong statement, as it can lead to poor governance and lack of accountability. CI/CD is not required to successfully manage minor changes, although it can help automate and streamline the process. See Application Lifecycle and Deployment for more details.

 Using a Source Control system alongside a multi-sandbox development strategy has several advantages, such as performing code reviews before promoting to a pre-production sandbox, keeping a history of changes made by each developer, and creating a branching strategy that tracks each feature or change separately. Automatically deploying changes from sandbox to production is not an advantage of Source Control, but rather a function of a Continuous Integration tool. Acting as a backup in case of catastrophic data loss is not an advantage of Source Control, but rather a benefit of having a sandbox strategy.

A product owner is responsible for defining the scope and prioritizing the backlog of the project. A product owner can help the COE manage the scope creep between the different projects by aligning the business goals and ensuring the value delivery. A scrum master, a release manager, and a change manager are not directly involved in scope management.

Designing the right sandbox strategy for the release is a best practice, as it helps to ensure the quality and consistency of the code/configuration across different environments. Regression testing is mandatory for each release, as it helps to verify that the existing functionality is not broken by the new changes. Maintaining a pre/post deployment checklist for each release is a best practice, as it helps to track the tasks and dependencies for each deployment. Release sign-off is not only required for Production, but also for other environments such as UAT and Staging. Publishing a release calendar for each phase of the release is not a best practice, as it may change due to unforeseen circumstances and create confusion.

Using continuous integration with automation testing is a development practice that will help to reduce the amount of bugs, as it allows the code to be built and tested frequently and automatically. Encouraging the development team to do peer code review is a development practice that will help to reduce the amount of bugs, as it allows the code to be checked and improved by other developers. Incorporating test-driven development into the project structure is a development practice that will help to reduce the amount of bugs, as it requires the developers to write tests before writing code and ensure that the code meets the test criteria. Enabling the development team to be self-organizing is not a development practice that will help to reduce the amount of bugs, as it does not directly affect the quality of the code. Enabling a short and timely feedback loop with customers is not a development practice that will help to reduce the amount of bugs, as it does not directly affect the quality of the code.