Now that we know how to deploy metadata using chain sets it's time for us to understand what all the
best practices that we need to follow while using change sets.
So what he had first comes the planning.
We should always plan other deployments.
Well not once and very much in the lean time.
Basically whenever the application usage is at its minimal.
Well during that time we should plan other deployments.
Let's say for instance we are planning a deployment from dev to Kuwait.
So therefore here we call it as the originating org.
And Kuwait is called as a target.
So whenever we are deploying metadata using chains it's from death to Kuwait.
That is from originating org to the target of the orders alternating or gets locked while we validate
a long chain set and the target ARG in our case Kuwait that is locked when we deploy it in bunching
set.
So when they say look what actually happens.
So when we say that a change it locks a particular.
Say for example def we can study a read and write data to the order that is def but we can't make any
set of changes that would modify the metadata so that is the reason we always say that deployments should
be planned well enough at once and in the time.
This is the first best practice that we need to follow next is validating chain set before deployments
validating a chain.
It is very essential before we deploy the chain that to a particular arc especially in production in
production.
If you are deploying a chain set that has guard any of the code components like triggers or classes
then validation is mandatory safe tools enforces validation for any of the chains it that contains any
code competence and does validation takes time.
It takes a lot of time depending on the test that we have a number on.
So it is always a best practice to validate the chain set way before the maintenance time.
You will say for example the maintenance as are the actual planned deployment to store model.
It is always a best practice to have the chains it validated.
Well I'd want to like one or two days and add ones that at least a few hours in advance.
So in case of any test that fails we'll have the time for troubleshooting that rather than running the
validation during the maintenance schedule and then running into errors and then sitting and fixing
them during the maintenance schedule which may be really become exhausted.
It is always a good practice to validate your chain set well in advance troubleshoot all the errors
and then be prepared for your deployment during the maintenance gate do.
This is definitely a very useful tip that we follow even in real time.
We have all the validations performed well in advance so that we can be little stress free during our
actual deployments moving on daily to rename competence using the web interface.
Yes we know that we cannot delete competence using a chain sets.
So what in case of deleting any competence or renaming any competence we have to go and manually do
that in the web interface plan for test to run in the target arg.
So as we already discussed validations is very essential before we deploy metadata into any target org.
But if it does sandboxes Salesforce does not enforce any mandatory validations even if the change that
contains any code components since those basically does not enforce validation.
However as a best practice you just always recommended that we perform test in on the sandboxes so that
we can catch any errors.
Well and once before we move ahead the production rather than doing the validation before the code applies
to production and then troubleshooting it there it is always the best practice that we run the validations.
Well ahead in the sandboxes and then fix any errors so that we have more comfortably during the production
deployment.
So always planned to have test run in the sandbox as well at once.
Even though Salesforce does just not enforce that next US cloning a chain set to add deepening competence
to an uplifting set so in this scenario consider we have two odds alternating autumn and the target
argh say that cute.
So in death the creator attains it and we have added all the components perfect and now.
Next what do we do.
We upload the chain set so we have uploaded the chain set to QB and know what happens in Def will not
be able to make any further a bit to the uploaded chain set right.
We know that a chain set which is uploaded becomes readable will not be able to make further updates
but in case before deploying the chains it took you away.
If you feel that this that are any missed confidence or if there are any changes that need to be done
then simply gone the chain saw it create a new version of the chain saw it and then use that to make
all your modifications adding or removing competence.
So long the chains it do all the modifications and then upload that wasn't to off the chain set to your
target.
Nexus and deploying all dependent components.
So what are dependent components.
I say for example we have created a custom object which has got some custom fields all right.
This is just an example.
And then we deploy.
Ensure that you apply both the custom object and the custom fields in case you missed out the custom
fields.
The deployment may still be successful but then only the custom object would be deployed but not the
custom fields so all the components should be deployed together for the functionality to work.
And in this scenario yes the deployment may be successful but there are many other scenarios within
the deployment might fail because of the god and competence being not present.
Say for example there is a trigger that is being deployed and for that functionality there is a custom
field that was created and that was also used in the trigger.
How valid when you deploy that trigger.
It would say that the field is not available because the field is not basically included in the chain
set.
So whenever you create a chain set include all the different components.
Just think about all the components that you created as part of that functionality include all of them
in your chain set
limit chain sets to 10000 files so as it says one chain it can have a maximum of 10000 files.
So if your change that exceeds this limit basically then what we do is like we split the chain set.
We split the companies accordingly.
Generally like we split in the reports on the dashboards and email templates in all these competence
separately because they have a list of dependencies then the other components.
So basically split the chain set and upload the target are and also white performing deployment.
Consider possible delays in the deployment time especially when the chains that includes changes to
some custom field types the deployment time.
It may be delayed by some extended period of time because this custom field type changes it requires
changes in a larger number of records right.
And that also depends on the data while you.
So basically what we do is in real time I will why these long delays.
The best alternative that we do is to apply those field type changes manually after the change that
is deployed.
So that is something that we do in real time.
So these are some of the best practices that we need to follow while using change sets.