Development Lifecycle and Deployment Designer : Exam Preparation Guide and Tips

First of all big thanks to everyone who follow my blogs and provide their valuable feedback. This motivates me to write something every month and share my knowledge by taking out time from so called busy professional life.

This is my 150th blog and have reached 500K pageviews with (500+ daily page views). Once again thanks to everyone!!

Along with this, I am really excited to get "System Architect" credential after completing "Development Lifecycle and Deployment Designer" Exam.

If you want to prepare about other exam for "System Architect" then refer below URL:

• SALESFORCE INTEGRATION ARCHITECTURE DESIGNER : Things to consider before appearing for this exam
• IDENTITY AND ACCESS MANAGEMENT DESIGNER : Exam Preparation Guide and Tips

Through this blog, I will be sharing some information which will help you to prepare for this exam.

As always, I started with trailmix Architect Journey: Development Lifecycle and Deployment designed for this exam. It has lot of information about different aspect for this exam.

Now I will specify different topics which will help you:

Migration Tools

• You should know the use case on when to use Change Sets, Force.com migration tool (ANT), force.com IDE.
• When you have separate release team for deployments, then being architect you need to make sure that all necessary components for deployment are specified in package.xml and associated metadata in .zip file to release management team.
• There are few exception which can not be migrated using Metadata API. So we have to deploy these components manually. Refer Unsupported Metadata List for deployments
• Custom setting can be migrated but custom setting data needs to be migrated manually after custom setting deployment.
• Prefer custom metadata types over custom settings if you want to migrated data during deployments.
• If you want to remove/delete certain metadata for clean up purpose, then create destructiveChanges.xml file and specify all components in that and then deploy using force.com migration tool. 

Sandbox Strategy

Salesforce offers sandboxes and a set of deployment tools, so you can:

• Isolate customization and development work from your production environment until you’re ready to deploy changes.
• Test changes against copies of your production data and users.
• Provide a training environment.
• Coordinate individual changes into one deployment to production.

Sandbox Types

• Developer Sandbox

A Developer sandbox is intended for development and testing in an isolated environment. Developer Sandbox includes a copy of your production org’s configuration (metadata).

• Developer Pro Sandbox

A Developer Pro sandbox is intended for development and testing in an isolated environment and can host larger data sets than a Developer sandbox. A Developer Pro sandbox includes a copy of your production org’s configuration (metadata). Use a Developer Pro sandbox to handle more development and quality assurance tasks and for integration testing or user training.

• Partial Copy Sandbox

A Partial Copy sandbox is intended to be used as a testing environment. This environment includes a copy of your production org’s configuration (metadata) and a sample of your production org’s data as defined by a sandbox template. Use a Partial Copy sandbox for quality assurance tasks such as user acceptance testing, integration testing, and training.

• Full Sandbox

A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and staging. Full sandboxes are a replica of your production org, including all data, such as object records and attachments, and metadata. The length of the refresh interval makes it difficult to use Full sandboxes for development.

When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.

• The default is to omit field tracking, but you can include up to 180 days of field tracking. If you track field history for many objects in your production org, specify fewer days to avoid generating an excessive amount of data.
• Chatter activity data can be extensive, which can add a significant amount of time to your Full sandbox copy.

Limit the amount of field history that you copy, and copy your Chatter data only if you need it for your testing use cases.

Sandbox Refresh Interval

• As a best practice, development and testing should not happen in same sandbox.
• If testing and development is happening in same org, then tester may face issues as development is going in same org.
•  Salesforce releases happen first in sandbox and then in production environment. So to identify if salesforce release will not impact your current development or features, test the functionality in preview sandbox (sandbox which is already upgraded to new release before production). 
• Salesforce sent notification about all instance or domain which are part of preview sandbox before every release. If your sandbox is not part of that, then raise request with salesforce to include your sandbox.

Continuous Integration

Continuous integration (CI) is a software development practice in which developers regularly integrate their code changes into a source code repository. To ensure that the new code does not introduce bugs, automated builds and tests run before or after developers check in their changes.

Using continuous integration, a product is built to include and integrate every code change on every commit (continuously), by any and all developers. An automated build then verifies each check-in, letting teams detect problems early.

Continuous integration (CI) is a component of the continuous delivery process that enables developers to integrate their updates into the master branch on a regular basis. With CI, automated tests run before and after each change is merged, validating that no bugs have been introduced.

• When you have multiple concurrent projects running along with new features, then always utilize the source control, build tool for deployment and automated test script.
• Continuous Integration Tools  includes Source Control Tool, Force.com Migration tool and sandbox environment where build can be validated and run automated test.
• Utilize unit and automated functional test script as part of continuous integration strategy.
• When multiple developers are working on different functionality along with bug fixes, then create separate branches for developers and merge their changes in common branch for testing.

Continuous Delivery

Continuous delivery ensures that code can be rapidly and safely deployed to production by manually pushing every change to a production-like environment. Since every change is automatically delivered to a staging environment, you can deploy the application to production with a push of a button when the time is right.

The additional step of pushing the code to a staging environment is what makes continuous integration different than continuous delivery. Having a green (successful) build with CI doesn't mean your code is production ready until you push it to a staging environment that matches the final production environment.

Continuous Deployment

Continuous deployment is the next step of continuous delivery. Using Continuous Deployment, every change that passes the automated tests is deployed to production automatically while continuous delivery is manual step.Most companies that aren’t bound by regulatory or other constraints should have a goal of continuous deployment.

While not every company can implement continuous deployment, most companies can implement continuous delivery. Continuous delivery gives you the confidence that your changes are serving value to your customers when you release your product, and that you can actually push that button anytime the business is ready for it.

Understanding Packages

A package is a container for something as small as an individual component or as large as a set of related apps. After creating a package, you can distribute it to other Salesforce users and organizations, including those outside your company.

• Understand the difference between manage and un-manage package.
• Manage package can be created in Developer edition and Partner Developer Edition.
• Aloha app is status given to manage package so that it won't count against limits imposed by SFDC. This is mainly utilized for Group and Professional editions.
• Unlock Packages 
• Unlocked packages help you add, edit, and remove metadata in your org in a trackable way so you can reuse components and upgrade your Salesforce apps easier and faster. They encapsulate all the metadata changes and updates you plan to make.
• These are especially suited for internal business apps.
• With an unlocked package, you have a lot of flexibility. Your admins can make changes directly in production in response to emergency change requests because metadata in unlocked packages can be modified in a production org.

Governance

If you have multiple teams working together and delivering different features at same time, then you need to establish governance to avoid technical debt on platform.  

Suppose each team is building different VF pages or installing different manage packages from appexchange, then their may be chances that developer are doing customization instead of referring salesforce standard capabilities. Also they spend additional effort on functionality which may be implemented by other team. Without governance, there are chances of multiple page layouts, duplicate fields or VF pages. 

• Center of excellence

This team can help to monitor if Salesforce development standards or practices have been followed or not and can also help in reducing the technical debt on platform. This team can emphasis on using Salesforce standard functionality instead on customization. This team can be involved in solution design reviews and can provide feedback before actual development.

• Change control board

Change control board can help in avoiding duplicates in system. This Committee makes decisions regarding whether or not proposed changes should be implemented. They can raise hand or point out if functionality is already existing in system. This committee can also help in monitoring the system limits and take decisions based on that.

Agile vs Waterfall Methodology

• Use agile approach if requirements keeps on changing based on end user feedback. This involves having DevOps for rapid testing and development. This is iterative approach in which we deliver features one by one. In this approach we estimate project time line and budget and will not have strict deadlines as requirements may vary based on end user feedback.
• Use waterfall methodology if project has fixed scope, timeline and budget. Also if requirements are pre-defined and end users are looking for complete product, then opt for waterfall.

Testing

• Load testing : This is considered as positive test as we monitor application performance with predefined load (concurrent operations).
• Performance testing: This test is performed to monitor response request time throughput and measuring mean time of application performance under normal conditions. This is also considered as positive test. For this we perform concurrent transaction to measure application performance.
• Stress testing : This is considered as negative testing. It is similar to load testing but we keep on increasing the load on application till application/server crashes down.
• Salesforce production is shared environment so stress testing is prohibited by salesforce. Salesforce impose lot of governor limits to avoid this.

Apex Hammer Test

Salesforce runs your org’s Apex tests in both the current and new release and compares the results to identify issues for you. The Hammer means taking every single Apex test that you or anyone else has created and running it twice.

Salesforce uses these results to identify any issues to resolve before the release.

Apex hammer test refer only those test classes which do not have access to org data.  The advantages of creating data silo tests are:

• Tests run more reliably because they aren’t dependent on data that can sometimes change.
• Failures from those tests are easier to diagnose.
• Finding bugs in the Hammer process is easier.
• Deploying from one org to another is more reliable.

Apex is not alone in running hammer tests.  Visualforce, packaging, Trialforce, and dashboards all go through a similar process.  The Apex process is the most involved, but the general principle of finding potential issues before you do is applied to all of these.

Hope this will help!!!

Best of luck for your exam!!!