Salesforce Development Lifecycle and Deployment Architect Certification complete test exam, Exams of Advanced Education

Download Salesforce Development Lifecycle and Deployment Architect Certification complete test exam and more Exams Advanced Education in PDF only on Docsity! Salesforce Development Lifecycle and Deployment Architect Certification complete test exam questions and answers Center of Excellence (CoE) - A few stakeholders from different functional groups work together to ensure that changes support business goals and follow IT best practices and processes. Release Management Team - Responsible for planning, scheduling, and controlling the build, in addition to testing and deploying Releases Governance Framework - Improves coordination by ensuring all members of your team are working together to achieve project deadline Design Standards - Follow key standards for coding, testing, integration, large data volumes, and other areas that affect the services you share with other Salesforce customers. Change Control Board - Committee that makes decisions regarding whether or not proposed changes to a software project should be implemented Executive Sponsor - Champions the project by acting as the project's highest level change leader - communicates the importance to stakeholders and senior leadership; obtains go- ahead decision and collaboration; is accountable for success; exercise strategic control to achieve project objectives and business benefits. Architecture Review Board - They will be responsible for defining the overall structure of a program or a system. They will also be overseeing IT assignments that are aimed at improving the business and ensuring that all parts of the project run smoothly. Steering Committee - Steering committee is a group of high-level advisers who have been asked to govern an organization or organizational segment and provide it with direction. Charter - Goals and the strategies to achieve with Salesforce. A clear charter helps the team to prioritize requirements, to focus on the area that meets their business goals as quickly as possible. Release Categories: Daily - Bug fixes and simple changes that do not require formal release management, including reports, dashboards, list views, email templates, and user administration. Minor - Changes with limited impact, such as a new workflow rule or trigger impacting a single business process. These releases typically require testing, but limited training and change management, and are delivered within a few weeks. Major - Changes with significant impact, including configuration and code changes with one or more dependencies. Because these releases greatly affect the user experience and data quality, they require thorough testing, training, and careful change management. Major releases typically occur once a quarter (or like Salesforce, three times a year). Releasing on the same day of the week for minor and major releases is a best practice. This allows for company-wide planning and sets expectations with your business users. In addition, don't schedule releases near holidays or other major events. Release Train - Scheduling technique for delivering application upgrades on a regular basis. Release trains are predictable and incremental, so they ease the development process by setting limits on how much can be done in any one development cycle Release Manager - Is in charge of managing: -The release schedule and coordinating releases with the business. -The source control system Sandbox Type vs Application - - An exclusive Developer or Developer Pro sandbox for development (one per engineer) - A shared Developer or Developer Pro sandbox for shared testing - For integration and user acceptance testing, shared Partial Copy sandboxes - For staging changes, a Full sandbox When to use Change Sets - -Point and click -Straight sandbox to production migrations -Change management without using a local file system -Auditing previously deployed changes -Enforcing code migration paths -Deploying the same components to multiple orgs When to use Force.com IDE - -Project-based development -Deployment to any org -Synchronizing changes -Selecting only the components you need Unmanaged Packages - A collection of application components that can be distributed and installed in other orgs. No namespace Best for: -One-time setup of a development environment -A starting point configuration that can be customized Limitation: -You cant't make further changes to packaged components using subsequent packages -Requires a Developer Edition org Managed Packages - A collection of application components ***with a namespace*** that can be distributed and installed in other orgs. Managed packages can be listed on the AppExchange and are upgradeable. Best for: -Commercial applications -Functionality you want to add in multiple, possibly non-related orgs Limitations: -Access to code is limited or hidden -Unique namespace can be bothersome or a blocker -Difficult to modify or delete components -Requires a Developer Edition org 9 Steps to Effective Change Management - 1. Get a strategy 6. Configure and test 2. Engage an executive sponsor 7. Communicate and train 3. Collect input from end-users 8. Deploy 4. Define scope and impact 9. Follow up & Support 5. Prioritize 6. Configure and test 7. Communicate and train 8. Deploy 9. Follow up & Support