Debug and deployment tools Flashcards
Describe how to monitor and access various types of debug logs.
A debug log can record database operations, system processes, and errors that occur when executing a transaction or running unit tests. Debug logs can contain information about:
- Database: Database changes
- Callout: HTTP callouts
- Apex Code: Apex errors
- Visualforce
- Apex Profiling: Resources used by Apex
- Workflow: Automated workflow processes, such as:
- Workflow rules
- Assignment rules
- Approval processes
- Validation: Validation rules
- System: system methods
Log Level
- NONE
- ERROR
- WARN
- INFO
- DEBUG (user debug is logged here)
- FINE
- FINER
- FINEST (don’t set this for Apex Code)
Places to Access
- Dev Console
- Trace flag set when console loads
- API calls
- setup ui
Defaults
- DB
- INFO
- APEX_CODE
- DEBUG
- APEX_PROFILING
- INFO
- WORKFLOW
- INFO
- VALIDATION
- INFO
- CALLOUT
- INFO
- VISUALFORCE
- INFO
- SYSTEM
- DEBUG
Describe the capabilities and security implications of the Developer Console, Workbench, and Force.com IDE.
Change Sets:
- 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
Force.com Migration Tool
- Development projects for which you need to populate a test environment with a lot of setup changes—Making these changes using a web interface can take a long time.
- Multistage release processes—A typical development process requires iterative building, testing, and staging before releasing to a production environment. Scripted retrieval and deployment of components can make this process much more efficient.
- Repetitive deployment using the same parameters—You can retrieve all the metadata in your organization, make changes, and deploy a subset of components. If you need to repeat this process, it’s as simple as calling the same deployment target again.
- When migrating from stage to production is done by IT—Anyone that prefers deploying in a scripting environment will find the Force.com Migration Tool a familiar process.
- Scheduling batch deployments—You can schedule a deployment for midnight to not disrupt users. Or you can pull down changes to your Developer Edition org every day.
Workbench:
- Ad hoc queries
- Deploy or retrieve components with a package.xml file
- Metadata describes
- Lightweight data loads
Force.com IDE
- Project-based development
- Deployment to any org
- Synchronizing changes
- Selecting only the components you need
Describe the different processes for deploying metadata and business data.
The process of moving metadata components from sandbox to production is often referred to as deployment. However, the term deployment is also used for a number of similar things, such as:
- Installing an app from the AppExchange and making it available to users
- Changing the operational status of new business logic (such as a workflow rule) from a state of in development to deployed
- Executing the contents of an inbound change set
- Sending metadata from one org to another
A deployment profile consists of a zip file containing metadata components and a package.xml file. The package.xml file is a manifest that lists everything being sent from the source org to the destination org. There are many metadata types, and you can have many components of a type, so the package.xml file can be long. But the good news is that you rarely have to create the file yourself. Most of the time the package.xml file is created for you. For example, if you’re using the Force.com IDE, the package.xml is assembled from the components you select when you create a project.
The exception is if you use the Force.com Migration Tool or Workbench. In this case, you create package.xml files for retrieval (the files you bring to a local file system) and deployment (the files you send back to the server). It’s often easier to create a project in the Force.com IDE and then copy package.xml and use the copy for the Force.com Migration Tool.
Deleteing
Administrators can’t delete components using change sets. As a result, they might resort to such tactics as deploying empty Apex classes to remove old functionality. This isn’t a particularly elegant solution, but it works well enough for admins that don’t have other means at their disposal.
To delete components, use the same procedure as for deploying components, but also include a delete manifest file named destructiveChanges.xml listing the components to delete. The file format is the same as package.xml, except that wildcards aren’t supported.
You can perform a deployment that only deletes components, or a deployment that deletes and adds components. In API version 33.0 and later, you can specify components to delete before and after other components are added or updated by naming the files destructiveChangesPre.xml and destructiveChangesPost.xml.
Describe how the different environments are used in the development and deployment process.
Sandboxes
Developer
Developer sandboxes copy only the org’s configuration, no data. You can create or load up to 200 MB of data, which is enough for many development and testing tasks. You can refresh a Developer sandbox once per day.
Developer Pro
A Developer Pro sandbox can store up to 1 GB of data (about 500,000 records). It’s otherwise similar to a Developer sandbox.
Partial Copy
A Partial Copy is a Developer sandbox, plus a sampling of data that you define in a sandbox template. You have limited control over the data that is copied. You can choose the objects, but not the records to pull. The sandbox can include up to 5 GB of data, which is about 2.5 million records, with a maximum of 10,000 records per object. You can refresh a Partial Copy sandbox every five days.
Full
A copy of your production organization and all its data. Because the Full sandbox is an exact copy, the amount of data in the sandbox is the same as your production org. You can refresh a Full sandbox every 29 days.
Using data in Sandboxes:
- Copy production data with Sandbox Templates
- Import via Data Loader or bulk api
