Building Questions Flashcards
What should Cosmic Tech Innovations’ architect recommend to manage the release complexity efficiently in their Salesforce development lifecycle, considering the need for isolated feature development and independent deployments?
- Adopt Git for source control and use the GitHub Flow branching strategy, enabling isolated feature development and independent deployments backed by the capability to restore previous code states if needed. (Correct - Provides isolated development and rollback capabilities)
- Utilize a source control system like Subversion and follow a trunk-based development approach, where all developers commit to a single branch and periodically branch off for releases. (Incorrect - Not suitable for isolated feature development and can lead to challenges with multiple release timelines)
- Implement a centralized version control system and adopt a feature-branch workflow, allowing each team to work independently on their branches and merge changes directly to the production branch when ready. (Incorrect - Merging directly to production can be risky without proper testing)
- Choose a distributed version control system like Mercurial and use a release-branch workflow, creating branches for each release and allowing teams to commit changes to these branches until the release is finalized. (Incorrect - Does not offer the same level of support for isolated feature work as GitHub Flow)
Cosmic Tech Innovations is working on an update for its custom analytics platform in Salesforce, which is structured using multiple unlocked packages to manage various application components. The project team has pinpointed the specific package (and its related dependencies) that requires enhancement to introduce an advanced data visualization feature. Considering the need to develop, test, and deploy this update efficiently with minimal setup time and without interference from other parts of the application, which environment should be utilized for the development of this update?
- A scratch org configured with just the package needing updates and its dependencies for streamlined development. (Correct - Provides an isolated environment tailored for focused development and rapid iteration)
- A Developer sandbox with only the targeted package and its dependencies installed for focused development. (Incorrect - Limited isolation level compared to scratch orgs and slower setup/teardown capabilities)
- A scratch org pre-configured with all existing unlocked packages for a holistic development view. (Incorrect - Unnecessary complexity and potential distractions from other system parts)
- A Developer sandbox containing the entire set of installed packages for comprehensive testing. (Incorrect - May introduce unnecessary complexity and distractions, slowing down development)
What three issues might an architect anticipate when reviewing the Apex classes and Visualforce pages in Cosmic Cuisine’s Salesforce org, which has undergone numerous modifications by various development teams over nearly a decade?
- Existence of multiple Apex triggers on the same object. (Correct - Can create confusion and unpredictable behavior due to overlapping logic)
- Repetitive code patterns across Visualforce pages and Apex classes. (Correct - Leads to maintenance challenges and inefficiencies)
- Obsolete custom classes for manipulating JSON data and strings. (Correct - Salesforce updates may introduce native features that make these classes unnecessary)
- Frequent unit test failures due to outdated test cases or code changes. (Incorrect - More indicative of inadequate maintenance and not specific to Apex classes or Visualforce pages)
- Disruption of functionalities due to Salesforce platform updates. (Incorrect - Less common and usually addressed through Salesforce’s notification and preparation processes)