CRT-450 Salesforce Certified Platform Developer – Testing, Debugging and Deployment – 17% Part 5

13. 6.3- Deploying Metadata – Demo

So I will first show you how we can deploy metadata using the force IDE. As we can see we have two different orgs here, I have added this, the 20 org. Let me go to its page. This is the 21 org and we have the 20 org. I would open the object think and as you can see there are zero custom objects. What I will do, I will deploy some metadata components from the 21 org. So I will deploy some objects. Let’s deploy the objects of the book cloud application. I will deploy these to the 20 org to do so on the force IDE. First we need to choose the metadata components. So in this case I will go to the objects folder and I will choose the custom objects. Step two is to rightclick and then go to the force menu item and then go to the deploy to server. I then need to provide the servers a username and password. This is the destination server. So in this case it will be a Walcode 20 server.

So the password is this one and I also need to provide the token. Let me get it from this and I will click on Next. Step two is optional. I can archive the project and the destinationforce. com components. Let’s do so. And I will use the same folder to archive these two. These are the six components that we have picked from the list. I can either click on validate deployment, this is mainly testing the deployment or I can click on Next. So let me click on Next. This will take some time and then I will have a successful deployment. Now I will go to the salesforce. org to the 20 org and I will refresh. There we go. Now we have the six objects. So this is one way to deploy metadata components, another way is to use packages. To do so I will go to the setup page, I will go to the 21 org and then let’s choose packages. I can either have unmanaged packages, this is the default or if I want to make this managed I need to change.

I will click on edit and I will specify a namespace and in this case I can build managed packages. But for now I will keep it unmanaged click on you. So I will do a bookscloud package. And now step two is to choose the components. So I will click on add and there I can choose the type of the component. So I can either choose an application, an Apex class, Apex trigger and so on tabs, fields, reports. So in this case I would choose an app, this app and I will add it to the package. When we add it, all it’s dependent metadata components will be also added. There you go. So we have all of this apps components, we have list views, we have custom fields, we have tabs and so on. Now I will click on Upload to upload this package. And to get the URL, I need to specify the name and the version, and I can optionally specify a password, some requirements and so on. I will keep everything the same and I will click on Upload. Now this package is being uploaded. That’s it.

The upload is now done. Note that I have a link. I can use this link to distribute my package. If I copy this, and if I share it with any person, he will have access to the metadata components of this package. But the very important thing is that I cannot control the distribution of this package. Why? Because this is an unmanaged package. I can also publish this package on the app exchange. So this is the second way that we can use to deploy metadata. The third way is to use change sets. But because I’m using a developer salesforce environment, I cannot show you that. And I will also not use my company’s salesforce. org because it’s a production and the sandboxes are used to deploy metadata to the production organization. So this is it for this lecture. We have explained how we can deploy metadata components between different orgs. We can use the chain set, we can use the force IDE, and we can use packages. And finally, as usual, thanks for watching.

14. 6.4- Salesforce Environments

Hey guys. This is section six, debug and Deployment tools. And this is lecture number four, salesforce Environments. In this lecture we will talk about what are the different environments in salesforce, what are sandboxes, what are their users and also we’ll talk about the development lifecycle. First of all, what is an environment in salesforce? Environments and organizations are exactly the same thing. So whenever we say environment or organization or we mean the same thing. An environment or has a unique organization ID and an environment or an. org has a unique username and password. This is just like any of your Gmail accounts. So each one of them will have its own username and password. Here are some important characteristics of an environment. First of all, it should be used for a specific thing. So it should be used for either development, for testing and so on. It contains metadata. It contains configurations like objects, like fields, Apex code, VF pages, workflow and so on. And it also contains data. So we have a difference between metadata of the configuration and data. And each environment is based on an addition which contains specific functionality.

Broadly speaking, we have three types of environments in salesforce. First of all we have the production environment. The production environments have active paying users accessing the business critical data. So this is where you go and where you open opportunities accounts and so on. This is the real environment. This is the production environment. And then we have the development environment. This is mainly where you extend your salesforce. org, where you build your salesforce. org, where you configure it, where you integrate it and so on. And this will not affect the production environment and it is built on a sandbox. And finally we have test environments. This is mainly where you test the metadata or the configuration that you have done on the development environment. And this is also built on a sandbox. So broadly speaking, we have three types of environments. We have the production, this is the real environment. And then we have the development. This is where we start. So this is where we build our salesforce. org. And in the middle we have the test environment. This is where we test the development before deploying to the production environment. Now, let’s talk about application lifecycle milestones. A typical salesforce application lifecycle consists of these milestones. First of all, we have the discovery phase.

This is where you get the overall application requirements from the business owner, where you get the features, the testing, integration and so on. And then we have the analysis milestone. This is where you analyze the requirements that you have gathered on the first milestone and you produce documentation. And then we have the build milestone. This is where you go and you create the configuration and the metadata and the sandbox and the development environment. And then we have the testing milestone. This is where you test this metadata and the testing environment. And finally we have the deployment milestone. This is where you deploy your metadata from the testing to the production environment. Now, let’s talk about sandboxes. What are sandboxes? A sandbox is an isolated environment that is used to build salesforce applications and test them. Sandboxes create copies of your salesforce. org of the production and separate environments and they are related to this production. Sandboxes are isolated from the production.

So operations that are performed in your sandboxes do not affect the production by any means. Application development and building should always start in the sandbox environment. We should never do development and application building and the production environment. And we have to use the sandboxes for development, for testing and for training. And by doing that, we are not compromising the data and the applications and the production. So, to make it simple, a sandbox is simply a copy of the production that is used to develop, to test and so on, without affecting anything on the production environment. We have many different types of sandbox licenses that we’ll talk about. Now, these are the different sandbox licenses. As you can see, we have four different sandbox licenses. First of all, we have the developer license. The refresh and Turbo is one day. So we can refresh the metadata from the production environment once every one day.

The capacity is 200 MB, the data capacity, and it includes the metadata configuration, apex and metadata and all the users. We have the developer pro. It’s the same as the developer, but it has 1GB capacity instead of 200 MB. And then we have the partial copy. The refresh is five days now, so we can only refresh once in five days. It has five gig capacity and it adds records sample of selected objects. So we can take a sample of data from the production environment. And also we have sandbox template support. Finally, we have the full sandbox. This is an exact copy of the production environment exactly the same. The refresh rate is 29 days and it includes everything that we can have in the production environment. So all the metadata and plus all the data. And we can choose not to include all the data. We can choose to include just a small portion of the data.

This is also a table summarizing the different types of sandbox licenses. As you can see, we have, first of all the refresh interpret one day, one day, five days and 29 days. And then we have the storage limit, 200 MB, one G, same as the production. So I don’t care what’s the size of the data, I will have the exact copy of the data and the production, or I can opt to choose a part of it and what’s copied metadata only on the developer and the developer Pro. But we also add sample data and the partial copy sandbox and sample data or full data and the full sandbox. And then templates. What’s a template? Template is just what part of data I want. This is available and the partial copy sandbox and the full sandbox. Now, based on my salesforce license, what sandboxes do I get? If I have the professional edition, I will get ten Developer. Sandboxes Enterprise, I will get 25 developer sandboxes and one the partial copy sandbox Unlimited I will have 100 developer, five Developer Pro, one partial copy sandbox and one full sandbox. And performance edition. I will get the same thing.

On top of that, you can buy any sandbox license except for the developer sandbox license for any salesforce edition that you might have. So if you need more sandbox licenses, you can go and you can buy them from Salesforce and this will be added on top of the sandbox license that you already have. Now, let’s talk about the development lifecycle process. This is mainly the different steps and the process that you need in order to start building your salesforce. org using different sandboxes and then deploying it to the production environment. It depends on the complexity of the salesforce application that you need and it depends on the size of the salesforce application. First of all, we have the single development and test environment. This is mainly using one sandbox for both development and testing before deploying to the production environment. This is used for small and big projects like new custom objects, tabs and applications, like integration with other systems, and like applications involving VF pages, workflow and the new validation rules.

And then we have the multiple development and test environment. This is mainly if one sandbox is not enough. First of all, we can use two different sandboxes, like a development sandbox and a test sandbox. And this is mainly used for medium projects. So we start the development and the customization on the development sandbox. And then we move this, we deploy this to the test sandbox where we do all the necessary testing. And then if the tests succeed, we move the metadata, we deploy to the production environment. And second, if two sandboxes are not enough, we can use more than two. This is mainly for larger and more complex projects that need several development and test environments. The environment can be multiple development environments for each one of the developers. A QA environment to gather the metadata from the different development sandboxes, a UAT environment as a user acceptance testing, a staging environment, and finally the production environment.

This is the alignment of the use case and the requirement with the sandbox license. As you can see, if we need a development or QA, a developer license or a Developer Pro license will be enough. If we want to do integration testing, batch data, test training and UAT, we need a partial copy, a sandbox license, and if we need performance and load testing and staging, we need a full sandbox license. So finally, in this lecture we have learned about salesforce environments. What are they? What’s the meaning of an environment. We learned about Salesforce application lifecycle milestones. We learned about Salesforce sandboxes what are they? And we learned about their licenses. And finally, we learned about the different development lifecycle processes. And finally, as usual, thanks for watching and good luck in your exam.