 Hello, everyone. I am Sanjay Gupta. I welcome you on Sanjay Gupta Tech School. So today we are having day 84 of this Salesforce learning bootcamp. And in this bootcamp, sorry, in this session, we are going to understand things related to deployment, right? So I have planned total three sessions on deployment. So today, tomorrow and day after tomorrow, we'll be having three different sessions. And those sessions will be delivered by Abhishek. So I have Abhishek Agarwal with me on this platform live. So welcome Abhishek on the channel. So Abhishek will be delivering all the session to you. And soon he will be introducing himself in front of you. But before that, let's quickly cover the upcoming week plan so that you should know what sessions will be delivered this week and next week, right? So moving forward, go to next slide. So before having the weekly plan, you can see we have this telegram group where lots of folks are connected and they are discussing things on daily basis. So if you want to become part of the community where lots of beginners and experienced folks are connected, so you can join this telegram group, right? You can scan this QR code and you can join it. So in the upcoming slide, you can see we have a day-wise plan. So here you can see next slide. So week 25, we completed LWC and currently we are having week 26. And in week 26, we are having sessions related to deployment. And after that, we'll be having three weeks back-to-back QA related sessions. So week 27 will be for QA, week 28 and week 29 for QA as well, right? So for QA sessions, I will be having someone else who will be delivering the session, right? And after that, you can see we have MOOC interview sessions planned. So nowadays, lots of folks ask me like, how we can present ourselves in interviews, right? So what I will be doing, I will become beginner, interviewee. And I will be having someone with me who will be asking questions to me. And I will be explaining how to represent yourself in interviews, right? So I will be delivering that MOOC interview as a beginner so that you can learn how we can explain, how we can relate real-life scenarios with the problem statements, right? So this is the bootcamp timeline for upcoming weeks. So moving forward, if you want to become part of Sanjay Gupta Tech School community, so in the next slide, you can see we have lots of social media information. So you can follow Sanjay Gupta Tech School on YouTube, LinkedIn, Instagram and Telegram. And on each platform, you will find different type of information. And if you want to follow the session tracker, so that link is available in the video description. And other links are also available so you can go through and you can follow whatever we are doing for you, right? And in the next slide, you can see if you really like sessions, so you can just provide reviews or feedback about the bootcamp so that I can improve the content. And if you need any particular topic, and if you want a bootcamp on particular framework or technology, so I can deliver that as well, right? So I can see lots of folks are connected, so 45 live numbers are increasing. And I am sure lots of people will be watching this bootcamp deployment related sessions, recordings as well, right? So welcome everybody. So moving to the next slide, so I think now Abhishek, Abhishek's turn and I pass on Mike to Abhishek so that he can introduce himself so that you get to know who will be your instructor for next three sessions. So over to you Abhishek. Thank you Sanjay for giving me this opportunity. So hi everyone, I hope you all are doing well. So myself Abhishek and I am working as a Salesforce and Velocity developer right now in Salesforce community. And I have in total around five plus years of experience, which includes, I mean, I started my career as a Salesforce developer. So for initial one and a half year to two years, I worked as a Salesforce developer, then I started my journey in Velocity development where first I just learned about Velocity platform essentials, which is known as OmniStudio developer in these days with Salesforce. So I'm working as a Velocity developer like since from three years. And I am a double star ranger and I hold five plus certifications, which includes OmniStudio developer, then I have Salesforce EPQ, then I have Service Cloud platform developer one and administrator. So that's that's all about me. Yeah, so maybe you can jump to next slide. Okay, so Abhishek is going to cover deployment. So he will be covering introduction first and will let you know information about different different sandboxes, information about different different techniques or tools, those are available for deployment purpose, right? So maybe we can start the session Abhishek. Okay. So in today's session, we're going to cover whatever what is what is what exactly deployment means in Salesforce in Salesforce domain. So whenever whenever you are working as a developer, whether you are an admin or you are a developer or let's say you are doing some sort of mixture of both, then in real time real real time scenario, you will be having a production all right. So so you never develop anything on the production or you always have to create a sandbox. So what is sandbox? So whenever you are purchasing a license from Salesforce, to build your functionality to build your whatever business case you have, you have so there will be a team of developers and admins who will be working around those functionalities. So for giving giving them the environment, we can create a sandbox from it from a production or which we have purchased from Salesforce. So so whatever develop development we are doing, we will be doing it into the sandbox sandbox or only. So now let's say you have developed your business case, your functionality. Now you want to now all the all the testing and all the SIT testing, UAT testing, all has been done. So then you have to make your changes live into the production order. So how you how you can basically, let's say you have created a field on an object account object. Now you want to deploy that field to your production. So if if you will be creating those fields manually in the production, all that will that will be a very time consuming task, right. So in Salesforce, we have we have a technology which is called deployments by which you can you can just fetch all your changes, all your components, fields, apex classes and anything like that, which can be fetched and can be deployed to your production or or if before deploying the production or we have a hierarchy to deploy to production or first we will be deploying all the changes to QA or then we'll be deploying all the changes to SIT or which consists of system integrated testing. Then you will be deploying your changes to UAT where you are all the business users will test your all the functionality, which is also called as user acceptance testing and then you will be deploying all your changes to the production order. So how we can fetch all the components from your sandboxes and how you can deploy it to your other sandboxes and deploy it to production or finally that is that is we're going to see in today's session. Moving on to the next slide. So, Sanjay, can you help me with this slide? Yeah, so basically Abhishek today I shared this information with the community. So soon we'll be launching one more bootcamp. So like in why I shared this coming soon image with the community today itself when I have Abhishek with me. So there is a there is a sink behind this image because I'm going to launch one more bootcamp soon starting from next week and that bootcamp is related to Abhishek as well or if I say like all those bootcamp sessions will be delivered by Abhishek. So I'm going to announce that a bootcamp name in front of Abhishek in this session because he is already certified in that area and he's expert in that area because he has done certification as well as he have done lots of project on that particular tool, right? So now I just want you to guess the name of that bootcamp. So if you can guess, so please write name of that bootcamp in the comment or chat section so that I can know like how much you listened about the introduction of Abhishek, right? So it is hidden in the Abhishek certification. So he showed five certification that he has done. So can you guess the name of the bootcamp that we are going to start from next week? Yeah, so I can see people are guessing it right. So four folks guessed it right, five, six, seven, eight. So I can see like Pratik, Nikhil, Nikita, Naveen, Samad, Subhashini, Nusrat, yeah, lots of folks are guessing it right. So those who are guessing it as Velocity or Omni Studio, so you are right, okay? So maybe Abhishek, we can jump to next slide. So the upcoming bootcamp will be on Omni Studio, right? So Abhishek is an expert in Omni Studio. He has certification. He has done lots of projects as well. So soon I will be sharing a detailed session tracker related to Omni Studio with you and those sessions will be starting from next week. So right now we have planned to do two sessions every week so that you can do proper practice because in Omni Studio everything we will be delivering through hands-on exercises, right? So we'll be explaining the concepts, like many things will be explained by Abhishek and I will be supporting him as well. So he will be explaining all the concepts, he will be doing all the demonstrations and we'll give you some assignments as well so that you can do some practice, right? So this is, I think this is great news for everybody because nowadays Salesforce is focusing more on industry clouds and in industry clouds we use Omni Studio a lot. So I think, I am right, Abhishek? Yeah, so I mean these days, so whatever, whatever solution that have not been touched by Salesforce, like insurance, telecommunication, media, energy and utilities. So those kind of solutions are already provided by Velocity, which is now acquired by Salesforce. So there are n number of opportunities in the Velocity and Omni Studio domain. So yeah, I totally agree with you. Yep, so I think now this is revealed like what we are going to have from next week. So soon I will be creating a session tracker and that will be available with the bootcamp session tracker, master bootcamp session tracker where all other information is available, right? So now we can proceed with the development, sorry, deployment related things, Abhishek? So let's move on to the next slide. So first of all, like we, I have already discussed about it, let's go through it again. So in Salesforce deployment typically refers to process of moving changes from one environment to the other environment. So as I said before, we always develop all the functionalities and business cases in the sandboxes only. We never do our development tasks in the production out. So first we have to create a production or we have to create a sandbox from a production out. And then in that sandbox, we can do all the configurations, customizations, like creating fields, creating objects, creating Apex class, LWC lightning web components and all other things. So deployment typically refers to moving one component from one environment to the other environment. So that is from introduction perspective. Yeah, so I just want to add one thing here, like if you are confused what is sandbox or what is production because I know lots of folks are freshers and beginners and you have not touched any company till now. So you are doing practice in your developer edition org, right? And in developer edition org, we have only one instance. So what is production and what is sandbox? So basically, when we purchase any licensed org, so that licensed org is basically known as production environment, right? So org and environment both are interchangeably terms. Now, whenever client purchase some licenses from Salesforce, and they have their production environment, so they tie up with any consultancy form, right? So consultancy form is responsible for doing their development testing, etc. Right? So they won't be doing these things in the production org. So what they will do, they will ask consultancy form to create copies of that production org. So copy of that production org is basically known as sandbox, right? And how many sandboxes we can create, it totally depends on that production environment upon which you are working. So soon Abhishek will tell you like what kind of sandboxes we have or we can create. And with the help of diagram, he will explain you like how we can deploy changes that we are implementing or doing in sandboxes. So we can deploy them from one sandbox to another sandbox or one sandbox to production, right? So yeah. So Abhishek, we can move on to next slide. Yeah. So first topic, when we talk about deployments, first topic that comes with that is data versus metadata, right? So what is metadata? Metadata is nothing but data which describes other data. So what do I mean with this line is? So for example, let's say you are creating a custom field on a particular object, right? So that field, on that object record, on that object you will be creating records. So that is called your data. And what is called metadata? So let's say on an account object, you are populating a name field. So there is already a name field created on an account object. So that name field called as metadata. So whenever you are creating any object, field, apex, class, or any component in Salesforce, there is a metadata maintained at the back end of the Salesforce. So so that we can retrieve those metadata. And after retrieval, we can deploy those metadata to another environment or another sandbox. So this is what is called metadata and data as we discussed. So whatever value we are populating on a particular field, for example, as we saw on account, we are populating a name field. So that name field, we are populating a value that is called data. And at the back end, there is a metadata created for that name field on the account object. So that's the main difference between data versus metadata. Right? Let's move on to the next slide. So this is what we were talking about. What is sandbox? So as we, as Sanjay also mentioned, we create a copy of our purchased license production or so that we can deploy our so that we can develop our functionalities or business cases. So we have four types of sandboxes, developer sandbox, developer pro sandbox, partial sandbox and full copy of sandbox. So full copy sandbox is not is similar to production or but but it's not a, I mean, this is a sandbox. So let's go to the next slide and we will discuss each and every sandbox. Yeah, I think everything is available in individual slides so we can cover from there. Yeah, sure. So developer sandbox characteristics we have. So we can, we can we can define the refresh interval, which can be one day. For the developer sandbox, that sandbox will get refreshed with the production on after each and every one day. And data storage of that sandbox is 200 MBs and file storage is 200 MBs and data storage is with 200 and what's copied. So that whenever you are creating a developer sandbox, your records will not get copied from your production on only the metadata. So let's say you have you have a field in your production or on an account object, which is a custom field, and you have created a developer sandbox from from that production on. So your records of accounts will not get copied to your developer sandbox, but your that custom field will get copied to your account object. Right. So do you have any questions in that? Yeah, so yeah, guys, if you have any questions, so please ask in the chat box. And we'll be answering each and every question at the end of the session. So Abhishek will cover all the questions at the end so that everything will be explained in sync in sync sequence. And then at the end, we can take all the questions. Yeah, so let's move on to the other sandbox, which is developer pro sandbox. Again, the refresh interval is one day, similar to developer sandbox. And here we have more storage. So file storage and data storage will be one GB for this sandbox. And in the developer pro sandbox also, only the metadata will get copied from your production or not the reports. Right. Then on to the next sandbox, which is partial sandbox. So the refresh interval of this sandbox is five days. So after five after each and every six days, your this your partial sandbox will get refreshed from your production on. And the data storage of this sandbox is five GB. And file storage is also five GB. And so it will copy the metadata as well as the sample data. Right. So whenever you are creating your sandbox partial sandbox, right. So at that time, whatever you have in your, so let's say you are, you have 10 objects in your production or and for that, each and every 10 objects you have 10, 10 records for each and each object. So those 10, 10 records will also get copied to your partial sandbox. Right. So in previous sandboxes, developer and developer pro, you will not be, you will not get your records from your objects, but in your partial sandbox, you will get your records as well. On to the next sandbox, which is full copy sandbox. So now you can see the refresh interval for this sandbox is 29 days. And default default data storage of this full copy sandbox is five GB. But we can, we can, we can get more storage by, by raising a case with Salesforce for that full copy sandbox. So it can be increased in the case of full copy sandbox. And in your full copy sandbox, all your metadata and all your records will get copied from, from your production out to sandbox on, right. And you must be, you must be wondering why the refresh interval is 29 days? Because we are, we are getting all your data from production or to your sandbox. So let's say if you will be having refresh interval of one day, one day, then it will be very difficult and it will be very time consuming to get all your records, all your, all your records on your, on your custom or standard objects each and every day to your sandboxes. So that is why the refresh interval of the full copy sandbox is 29 days. Yeah. So Abhishek for this, I shared one link as well in the chat. So guys, if you want to have more text information, so I just shared one link in the chat, which is our official Salesforce document. So you can also go through with that. Yeah, please carry on Abhishek. Yeah. Thank you Sanjay. So now we will see how, how a real-time, real-time project development looks like, right. So first you will, you, you will be purchasing your production license or from Salesforce. Then from your production or you will be creating a full copy sandbox, which will be called as UAT and the full form of UAT is user acceptance testing. And from that, your full copy sandbox, you will be creating your partial copy sandbox, which can be called as QA, quality assurance sandbox. And from that, your QA sandbox, you will be creating your developer sandbox. And so when you are, when, when consulting companies works with any client, so they, they can go with multiple approach. So let's say on a particular object, five, five developers are working. So one consulting company can create five developers sandbox for each and every developer, or they can create just one developer sandbox where all the five developers will be working. So it's up to consulting companies, how, how they, how they follow the process. So it can be, it can be in multiple ways. Sometimes between Q and UAT, consulting companies create one more sandbox, which is called a system, which is called as SIT sandbox, system integrated testing. So whenever you are developing a, developing a functionality for a client, right? So first of all, you will be developing and building your functionalities in developers sandbox. Then let's say five developers are working, then all the five developers functionalities will go to your QA sandbox, where your QA will test all the things whatever, whatever has been built. Now let's say there are, for your, for your client, you, there are two modules that are being developed into the separate, separate developer sandboxes. So on one sandbox, I am working and let's say for one sandbox, Sanjay is working. So we will be, we will be deploying all our changes to, so there will be a QS sandbox for me and there will be a QX on sandbox for Sanjay as well because he's working on a different module and I am working on a different module. Now from QA, we will be having two QS sandbox and after then we'll be having a SIT sandbox, which is called a system integrated test. So that my functionality and Sanjay's functionality can be deployed to one sandbox and that can be, that can be tested as a integrated system. Like there is a possibility that Sanjay's functionality is working on their own its own and my functionality is working on its own. But when we are combining those, then it can get failed. So that is why we have a concept of SIT testing. And after the SIT testing, it goes to UAT testing where end, end customers and end users will test all the functionality and most of the times all the UAT testers are from the client side. So consulting companies works finishes off after the SIT testing and after the SIT testing, UAT testing is done by the clients and when they pass all the test cases in the UAT sandbox, then we deploy all our changes to production, production on them and that production deployment also called as go live. So I hope everybody understood very well with the help of this diagram. And as Abhishek explained you, like we have production and through production, all these sandboxes will be created as a copy. And in developer sandbox, we'll be having only metadata, no data. So developers, if they are creating any new functionality or changing something, which is already built, so they will be creating their records at their own. Right. And for partial and full copy, you will be having some data in partial, you will be having some data. And in full copy, you will be having all the data. Right. So like with this flow, like in interview, if someone asks you like, have you ever done deployment or you do you know about deployment? So with the help of this diagram, if you explain things, so it will make more impact to the interviewer. Right. So just just have a screenshot of this slide in your mind so that in future, whenever you will be explaining about deployment life cycle, so you can explain this and SIT is also important, which is in between QA and UAT. Right. So that also you need to consider. Okay. So I think we can proceed further. And guys, if you are having any questions, so please ask that in the chat. And after the completion of the session, we'll be answering all your questions. Please go ahead, Abhishek. Yeah. Now we will see, I mean, Salesforce supports various deployment methods. What do I mean with methods? I mean, if you want to deploy your, for example, let's say, one custom field from Sandbox to your other Sandbox production, there are multiple ways you can do it. So those methods named as chainsets, workbench, and then we have Salesforce CLI tool, which is also called as end tool. And then with the help of VS code, also, we can deploy our components to the others and boxes of production. Then we have, we have this Salesforce DX, which is, which is a Salesforce, Salesforce functionality by which also we can deploy. Then we have that metadata API. Then for installing managed packets, so that also we can support in deployment methods. Then we have continuous integration and continuous deployment. So what we do is, I mean, above all the methods are manual deployments, right? But with the help of this CI CD tools, we don't have to deploy our changes manually to any of the Sandbox or production. We can deploy our metadata files to the CI CD tools like we can have a repo on GitHub. And on that GitHub, we can set up the CI CD tools so that deployment will be happening automatically. So this thing we will be, this thing we will be seeing in more detail in future sessions, but all other deployments, methods are manual deployments, but this CI CD tool is an automated deployment, which can be done with the help of GitHub. And at last, we have third-party tools like Copado, Flosam, and Gearset. So these tools are offered by some other companies which are point and click tools. So for example, if we take Copado, right? So we will be installing a managed package from Copado in our Salesforce app. And then it will be a UI tool from where we will be selecting all our components. And with the point and click, we can deploy our one component to Sandbox to another Sandbox. This is a feature that has been given to us by some other companies on the same source. Yep. So I hope everybody gone through with this slide. So like in your interview, like if someone is asking, have you ever done deployment? Like if you have experience, and if you are a fresher, so if someone asks, like, do you know about deployment, which tools are available? So this is the list, right? So you can just name all these methods. So if you know, like no one, or maybe like few, few developers or few release managers or release engineers know all these tools, right? So you don't need to know all the tools. If you know two to three tools or methods like how they work and we deploy the things. So that is enough, right? But you should know, like very, very little or very less details about each and every method. So in upcoming slides, like Abhishek will be explaining each and every method in little detail so that you can understand what exactly we can do with the help of these methods. And here, one thing like Salesforce DX, it is a tool provided by Salesforce itself, and it is like Salesforce developer experience where you can do deployment. And one more thing that you need to, like again, recall. So whenever Abhishek or I says, like we deploy components from one environment to another, and I can see one question in the chat box, which is related to this. So when we say component, so we are talking about metadata. And when we say metadata, so metadata means like if you have created any object field, or you created a flow, you created an apex class, you created a trigger report dashboard. So all these items if you want to deploy, so basically you will be deploying their metadata and metadata is like data about data. So you will be picking those items with the help of their API names and data like records that you are creating that is separate. So records, we cannot deploy record, we need to like migrate, we can migrate data through tools like data import wizard or data loader. So data is separate and metadata is separate. So you just need to remember this thing in your mind. So whenever we say component, it means we are talking about metadata items. So I hope someone asked that question. So I think it is being answered. And now we are moving forward so that we can understand each and every method. So in today's session, we'll be talking them theoretically. And in tomorrow's sessions, Abhishek will be doing some demonstration and so on. So he will walk you through like how we can do deployment from one org to another, right? So yeah, so we can move forward Abhishek. Yeah. So first method, which is which is named as chain set. So chain sets are simple point and click tool where you where you will be creating where you will be creating chain sets in your from your setup in your Salesforce org. So when you click setup in your Salesforce org, in the search bug, you can search for inbound chain sets and outbound chain sets, right? So when you want to deploy, deploy, let's say one, your custom feed, you will be creating an outbound chain sets. And in that outbound chain set, you can name anything that chain set and you can select your custom free field from there. And after creating your chain set, you can upload that chain set to your production or any other sandbox, right? So this is this is again a point and click or UI tool which by which we can deploy all our components. So yeah, this is the first one. And if we go to next one, we have one. Yeah, so one thing I want to add Abhishek with chain set. So chain set is like provided by Salesforce itself, right? So you don't need to install anything. It will be available inside your sandbox. And through production, you can manage like you can do inbound and outbound. So you don't need to install anything. And unfortunately, like we don't have any licensed or so we won't be able to show you like how we can deploy through chain set. But if you search on internet, you will find some blocks where some like screenshots will be available so that you can visualize. And if you are working in any company already, so in that company, like if you're working on sandbox or production, so then there you can just search for inbound and outbound chainsets. So you will be getting more details about it there. Right. So moving to next method. Yeah. So next method is called as workbench. So when you when you will be such you will be searching for workbench Salesforce, then again, you don't need to install anything in order to deploy it through the workbench tool. You can just go to work. I mean, you can search for workbench in force and there will be a link on which on which you can connect to your production or sandbox or by entering your credentials, user ID and password. And from that user user ID and password, there is there is an option where you can retrieve your retrieve your data from your sandbox. So let's say there will be a there will be a link in the workbench from where you will be retrieving all your components. So in chainsets, we don't have to retrieve our components and then deploy it. But with the help of workbench, you have to retrieve your components first, then you you will be deploying your components to the other production other sandbox or production. So for for workbench, there is there is a file which is called as package dot XML, which will contain all your metadata information that you that you want to deploy. So for example, let's say you want to deploy a Apex class. So you have you have to create a package dot XML that we will be seeing in the in today's session only how that package dot XML looks like. And in that package dot XML, we will be giving the information about our apex Apex class name. So that that package dot XML will contain your all the metadata information that you want to deploy from one sandbox to another sandbox. And that we can do with the help of workbench. Yeah, so maybe Abhishek we can show right away. So you can jump to the browser tab and maybe even show like how we can open workbench. I think many of audiences beginner so they can see. Yeah, sure. I think just escape and if it is in the same browser, so it will be available. Yeah, I think I have to because that escape is not working. So I'll stop sharing for once and okay, yeah, yeah, that will also you can reshare. So is it working now? Yeah. Yeah, now just just show the package dot XML and maybe if you can open workbench.com. So yeah, so guys, you can see like you can just search for workbench in the Google and you can open it. Yeah, I think you can proceed now. You are not audible Abhishek. I think you are on mute. Yeah, my bad guys. So in Google, you can simply search for workbench Salesforce. And when you will be when you will be clicking the first link, you will be redirected to this redirected to this website. And on this website, as you can see, we have we can select the environment, whether it is a production environment or the sandbox environment. And then we have to select the API version. So latest API version, which is supported by Salesforce is 58. So whenever whenever a new release comes, Salesforce might update the API version to support or to incorporate incorporate changes, whatever Salesforce functionality we have. So Salesforce is providing the API version. Then we can simply click on the I agree and terms and condition. And we can go further. And then you will be redirecting redirected redirected to your Salesforce login screen. And over here, you can provide or you can provide your user ID and password. And yeah, I think that we can cover fully in the upcoming session. So just show the practice dot XML and then we can proceed further because we need to cover all basic things today. Yeah, yeah. So your practice dot XML looks like this. So I mean, it's kind of a kind of a tag tag file, where you will be having the parent tag as package and you will be providing this API API link endpoint, which can which is at store dots as for dot com and so on. Then you will be having a sub tag called as types, right? Can we zoom in? I think it is. Yeah, yeah. Very less. Sure. Yeah. Now, yeah, it is better. Okay. So in the in the types tag, you will be having a you will be having your, let's say for apex class, your types sub tag name will be named as apex class. And in the members tab, you will be having your apex class name. Similarly, if you if you want to add one more, one more, let's say apex class, so you will just copy your members tag. And in in another tag, you will be giving your another apex class name. So this is how your package dot XML looks like, which will be containing all your metadata information, which you want to deploy. So I think that that would be all for now. And we will be seeing more in detail in future coming sessions. Yeah. So Abhishek will be doing this workbench deployment demo. So that that he will be covering in the upcoming session. So back to the slides so that we can cover rest of the methods. Yeah, this is what we have covered and we have Salesforce CLI. So Salesforce CLI is a command line tool, where you will be where you will be retrieving all your metadata information with the help of command line. So this is not a point and click tool. You have to install you have to install one application called as and and with the help of and you will be you will be executing some command commands on that end command line tool. And with the help of that, you will be fetching all your components. And then you will be deploying it to your production or any other sandbox. So it needs a further application, which needs to be installed your installed in your system. Then onto the next method, we have Salesforce extensions for VS code. So what usually we do is we connect our VS VS code with your with our Salesforce Salesforce environment, right? So for for connecting our VS code to Salesforce environment, we install one extension, which is called as SFDS, right? Salesforce CLI. So with the help of Salesforce CLI, we can we can again fetch all our components with the help of package.xml. So we will be creating a package.xml, which will be which will contain all your all your metadata information that you want to deploy. And then with the help of that extension, you can retrieve all your data and then you can deploy it to your Salesforce another environment. So again, this method needs a VS code installation and SFDS extension that needs to be installed in VS code. So this is another method. Then I think this VS code method will be covering right in demo. Yeah, we will be covering that in the demo. For the next one, we have Salesforce DX, which is developer experience. So basically with the help of this Salesforce DX, again, this is a tool provided by the Salesforce from which you can retrieve all your all your metadata and you can you can deploy it to your another Salesforce environment with the help of the end. This is this is again, you have to install an application for this. And it's pretty much the same. It's pretty much the same as like we are doing with the end tool, but that end tool is a command line tool. And this is the Salesforce DX is not a command line tool. It's a UI UI kind of tool. So yeah, one one important thing here, if you go through the third point, so it says it uses scratch orgs for development. So someone asked me what is scratch also scratch org is basically a copy of your product, which is having no metadata. So you can develop something from the beginning and like it is it is for a short period of time. And like you can deploy. So basically in in few projects, each developer want independent orgs. So in that case, like we can have the concept of scratch org on to the next method metadata API. So metadata API is a web service which is provided by Salesforce. And again, we have to create a package dot XML for this one. And by uploading that package dot XML, you can retrieve your data and deploy it to your target org. And one more thing for metadata API is it can be automated also. So let's say for example, you have created one your one package dot XML, which contains all your metadata, and you want to you want to do it repeatedly. Let's say every 10th day. So with the help of metadata API, you just have to upload your package dot XML and that will be deployed and you can set the interval and by which you can deploy all your changes to target orgs on a repetitive basis. You don't have to do it manually in each and every time. Right. Yep. So we can move to next slide. Yeah. So manage package. So for manage package, what what you have to do is um, so let's say you have installed a managed package in your production all, and when you will be creating your sandbox from that production all that managed package, that managed package will be available in your sandbox automatically. And but for example, let's say why you are developing something in your sandbox, right, and you have installed a managed package in your sandbox. Now you want to uh now you want to deploy that managed package to your production all. So with the help of deployments to you cannot do that. First, you have to install that managed package manually in your production all. Now, let's say on that managed package, there is a object on which you created 10 custom fields. So those 10 custom fields can be deployed with the help of deployments methodologies. But you cannot but you cannot deploy a managed package. First, you have to manually install your managed package in your production all. Then only you can deploy whatever changes, custom changes you have made on the managed package. Yeah. I just want to add one thing here. Like we have two types of packages. One is unmanaged and another is managed package. So basically, if you have heard about app exchange, so through app exchange, we can download pre-built packages where lots of configuration is already implemented and components are there. So a few solutions, like if you want ready-made solutions, so you can download packages from app exchange and like unmanaged packages, you can do some changes, but in case of un in case of managed packages, you won't be able to modify things. You can create new new components on top of that, but that managed package will be controlled by the creator. So these two types of packages are available and if you want to see what managed or unmanaged packages are installed in your org, so in setup, you can just search installed packages and there you can see the list of installed packages. So for this, first you need to create the package and then only you will be able to install it. So it is another kind of, it is not directly a deployment process or method, but like if you want to have pre-built packages installed in your org, so you can say like if you install managed or unmanaged packages, so from one org, you are like deploying some components into another environment, right? Okay, so we can move ahead. Onto the next one. So we have some CI CD tools by which you can automate or continue, you can deploy continuously on your target or environments. So when we are taking help of CI CD tools like Jenkins as your DevOps Circle CI, so what we do is we just create a repository on, for example, let's say I have created a repository on GitHub, right? So you will be maintaining all your metadata on your GitHub and you can automate your GitHub repository with the help of those Jenkins tools, Jenkins or CI CD tools. So I'll take the example of Jenkins and the Jenkins, what you can do is you will link your GitHub repository with your target or which can be a sandbox or which can be a production arm. So whenever you are making any changes on the developer sandbox on which you are working, what you can do is after making your changes, you can retrieve all your changes with the help of package.xml and those changes you can deploy it to GitHub repository. And once you have deployed your changes to GitHub repository, that Jenkins CI CD tools will, we can trigger the Jenkins CI CD tool which can deploy whatever we have in your GitHub repo that can be deployed to your target environment. So in previous examples, we were deploying all our changes from one sandbox to another sandbox manually, right? When we are doing the deployments from the VS code, we were just retrieving the changes, then we were deploying it to the production or any other Salesforce environment. But with the help of this CI CD tools, you just need to, you just need to change, you just need to upload your changes to your GitHub repository. Then with the help of this Jenkins CI CD tool, those changes can be automatically deployed to your target environment. So this is also one of the methodology by which we can deploy our changes to one environment to another environment, right? And this is the one which is we use mostly in our projects because there can be a possibility like 10 developers are working on a same requirement, right? So if we want to manage all of their changes, so we usually create a GitHub repository where all the developers will be committing their code or uploading their code with the help of metadata package.xml. And from that, all the changes that we have received on the GitHub repository, we deploy those changes to target org, let's say each night or each, let's say in each on the weekly basis, something like that. So this is the most common methodology that we use. Exactly. Yeah, so on to the next one. Then we have these third party tools like Copado, and we discussed more like awesome and all these things. So these third party tools have been developed on the Salesforce platform. So we'll take the example of first example of Copado, so that Copado managed package is implemented on the Salesforce platform on which we have all the, this is a tool where you will be seeing your components on the UI. You don't have to create any package.xml. You don't have to retrieve it and you don't have to deploy it. You will be just connecting your source org, which can be a developer sandbox and the target org, which can be your key way sandbox or production or environment. So you just need to do three things. First, you will be connecting your source as source org and the target org. Then you will be selecting what components you want to deploy. And then you just need to click one button, submit, and it's something like that. And all your changes will be deployed to your target org automatically. So these kind of third party tools that have been developed on the Salesforce platform, which can also be used. For example, if you want to use Copado, you have to purchase since managed package from App Exchange. So that managed package will get installed in your sandbox. And then you can start using this Copado third party department tool. Yeah. And for your knowledge, like Copado is an independent company and it is not directly related to Salesforce, but they implemented their tool on top of Salesforce platform. And they hired developers, QAs and other consultants as well. And nowadays, like lots of community events, like I attended one community event, which was related to Copado in Jaipur. So like, if any time if you get a chance to be part of that event, so you will be able to learn more about Copado there. And I will try to have a like separate bootcamp on Copado if I find someone who is expert in Copado, because very, very less consultants are available who are working with Copado. And I think it is paid tool. So it is not available freely. So that's why it is difficult for us to explain you. So I am working on that. And if I find someone socially, I will be having someone who can show you some demonstration like how Copado look like and how we can do deployments from one environment to another. Okay, yeah, we can move. So another third party deployment tool we have as Gear Set. So Gear Set is also kind of a similar tool like Copado. I mean, you can just connect your source or can the target or and by selecting your components, you can deploy you can deploy your changes to the target or exactly. And and both Copado and Gear Set are UI tools, like you don't need to create any package.xml, you don't need to write any command. So you will see UI, you just need to point and click select source components and you just need to select the target environment and components will be deployed. So it is like very easy for us to use Copado or Gear Set. So it depends like in your project, what kind of deployment method is being used. So if you know any any couple or two to three of tools, so you can easily pick like if someone guides you like this tool works this way. So like on on baseline, you know how deployment is happening. So if you know any of the method for deployment, so you will be able to pick any other deployment method quickly if someone guides you. So we'll try to cover three methods in upcoming sessions so that you can understand different different aspects like how we can do deployments. So we'll be covering workbench, we'll be covering Visual Studio Code, VS Code and one, what is the third one Abhishek? We'll be covering and migration. Yeah, so there we'll be using command line interface. So commands will be there. So these three will be demoing and rest of the tool, I think if you work in a company, so you can pick up from there. And if you are a fresher and in future, whenever you get a chance to work with a company, so basis on the requirement of the project, you will be able to understand that concept very well. Okay, so I think we have one more. So we have one more deployment tool which is called as Flossom. So I mean, this is again a deployment tool similar to Copado and Gearset, but that Flossom will create your repository as well. So whenever you are doing the deployments, we discussed about the CI CD tools with the help of GitHub, right? So with the help of Flossom, you can deploy your changes to your target org as well as you can maintain, you can maintain your repository as well. So that extra feature that Flossom gives other than that, everything is similar to Copado and Gearset. Okay, so I think all the things are covered. So now I am going to show the chat. And yep, so Abhishek, if you can stop screen share so that I can show the chat. Yep. Okay, so I think Abhishek, you are able to see my screen. Yeah, I can. Okay, I am scrolling down so that we can see the questions. Okay, so starting from the beginning. Okay, so I think scratch org we already discussed. Then we have a question like is the org that we create in Trailhead as sandbox? So no, Trailhead is just a playground. It gives you playground where you can do some implementation. Sandbox, like if you have a production org and you create a copy of that production, so it is basically known as sandbox. So with Trailhead playground, you cannot create sandbox. And with your developer addition org, you cannot create sandbox. And so Bhashini asking what is refresh interval and is refresh automatic. So I think I just shared this link and if I show you this thing, so here things are written clearly. So once you refresh the, so refresh is not manually. We need to do refreshes and like this is the limit. So in one day, you can refresh developer sandbox in one day interval, you can refresh developer pros and bucks. And for partial data, it is five day and for full copy, it is 29 days, right? So with this link, you can get more clarity. So Ashutosh, yeah, I would say yes to this. Rinku is asking, can we update refresh intervals? So I think no, right Abhishek? No, I mean, that is already defined by the refresh intervals. We cannot do that. Right. So next is refresh works for if we have production org for our developer org for practice doesn't get refreshed. Right. So for developer org, which you are using for practice, we cannot create sandbox. And if we don't have any sandbox, so there is no concept of refresh case. So next is Vinay is asking some other questions. Suppose we have the production metadata more than developer sandbox size. And we are trying to create sandbox using that I will create, it will create on throw or throw the error. So Abhishek any idea on this? I think it will. So, I mean, the thing is your, so whenever you are creating, let's say a developer sandbox, your metadata cannot be more, I mean, more than, if it is more than your developer sandbox size, it will throw an error, then you have to select what are the metadata that you want to fetch or retrieve in your sandbox. So you can decide what you need in your sandbox as well. Okay. And next is developer sandbox will be empty without any data. So yes, right. And we copy data from lower sandbox to higher or higher to lower lower. So if you are talking about data, so data we copy from higher to lower, like production org data, we can have in full copies and box. Right. And in partial copies and box, we can have sample data. And for migrating data, like if your client is having any legacy system, which is not built on Salesforce, and as a solution to that legacy system, if you have created Salesforce CRM, so client may ask like they want to migrate their data from legacy software to Salesforce. So in that case, you will be doing data migration, right? So that is done by data consultants. So here in this deployment case, if you're talking about data, so we move data from higher to lower environment. And in lower environments, basically, data is not available. We have only metadata. So there is one more question file storage doesn't count in data storage, how they are different. So when you upload, let's say you are uploading an image, right? So that that will be considered in the file storage. And when you are creating any sort of data, let's say an account report, that will be considered data data storage. Okay, so next Shubhashini is asking who is responsible for creating the sandboxes. So usually, usually there is a DevOps team in each and every consulting companies. So they are the responsible for creating the sandboxes so that developers can build their functionalities and use cases. Right. And in case like DevOps team is not available. So maybe any admin or developer can do because it is straightforward, you need to go to setup in production org and through that you can create a particular type of sandbox. And whenever you spin a new sandbox, so whatever user you have in production org, so those users will be notified with the sandbox and they will be able to log in. Right. So for package development, will it be different? So I think package development is a different process. It is not a deployment process, which are from these users tooling API for deployment. I don't have any idea about this. Abhishek, do you have? I mean, I'm not able to understand this question. Yeah, actually, because tooling API, I think it is not related to deployment at all. Yeah. So yes, while we are not sure with this question at the moment, so we'll do some research and if we find something, so we'll clarify your question in tomorrow's session. So Nikita is asking, sir, please explain again CI CD. So briefly Abhishek, can you just? Yeah. So if we talk about, let's say, other methodologies like work bands, deployment through the VSCode, those are all the methodologies where you will be retrieving your data manually and you will be deploying your metadata to target or manually. But with the help of CI CD, what you do is you just set up your repository on, for example, let's say you are setting up your repository on GitHub. So you can link your GitHub with your target or with the help of CI CD tools like Jenkins. Jenkins is one of the CI CD tools which with the help of Jenkins, you can link your GitHub repository to your target on. So now as a developer, what I have to do is I will just retrieve my metadata and I'll be deploying or committing my metadata to GitHub repository. Now I don't have to deploy it to manually to the target or that part will be handled by the Jenkins. So this is, this can be explanation of CI CD tools. Yeah. So I think you can explore about it more, Nikita. So we just gave you a little bit insight. So just go through with this and maybe if you have more doubts, so you can ask in the telegram group. Next is how to perform deployment activity through Azure DevOps, if you could show any example. So I think it is as your, like, we are not able to show you the demonstration as of now. So for this, like I can say, for these kind of tools, I will be having separate DevOps bootcamp. So I have one consultant who is preparing something on DevOps, right? So whatever we showed in today's session, apart from that, if it is related to DevOps, so that we'll be covering separately, right? So I hope Punker's communication is good now. I'm not sure whether you are live right now. So Saida is asking, Postman method also deployment tool. I don't think so. Abhishek, are you sure about this? Postman is just for integration. For testing, just testing your integration with any sort of API. Yeah, so it is not a deployment tool. Right. So it is more related to integration or maybe you can say integration testing. Nikita is asking which deployment method is mostly used in projects. So I think it depends on your project, actually, like which which method project team is basically using. So we cannot say which one is used frequently. It depends totally on your consulting firm or project, right? So next is, is there any to identify the component or candidate for deployment or is manual process? Yeshpal, I'm not getting this question. Can you please ask it again? So someone is asking XML file like LWC. So Abhishek, package.xml. So no, so LWC is a file which will contain like HTML, JavaScript and again XML file, which will contain all your all your, let's say, configurations related to that LWC, like which API version it will use? Is it exposed to community or not? But package.xml is completely different. That package.xml consists of the metadata that you want to retrieve from your Salesforce R. So with the help of package.xml, you can retrieve your components. So LWC.xml is different and package.xml is different. And I think in your demo, it will be shown. So it will be clear then, right? Yeah. So Yeshpal, this XML file will be like Abhishek will be demoing practically. So I think then your doubt will be cleared. So Yeshpal is asking Salesforce DX runs Salesforce CLI behind the scene. I'm not sure about this. Abhishek, do you have any insight? I mean, behind the scenes, whether you talk about change sets, you talk about workbench, you talk about VS code deployments. Behind the scenes, Salesforce have their own functionality built on. So we cannot, we cannot say this functionality runs behind the scenes at the Salesforce DX. Okay. So next is Prateek is asking what is package.xml. So I think in tomorrow's session or maybe day after tomorrow, whenever we will be having session on VS code like deployment through VS code. So then you will see package.xml actually. And I think Abhishek, you showed package.xml today as well. Right. And in workbench also, we'll be using that. So we'll discuss more on package.xml in tomorrow's session. So Bhashini, yes, most of the method uses package.xml. Can we reuse the same package.xml across all? So Abhishek, yes or no? So I mean, it's up to you. I mean, package.xml is a file from which you will be retrieving your better data. So you can use a package.xml with workbench, with VS code, anything. Right. So answer will be yes. Like we can reuse, but it depends. Yeah. So next is if you want to deploy using package, so on sandbox, shouldn't we have unmanus package? So we can again create a new package version. So I'm not getting your question, Yashpal. So if you can ask it again. So CI CD creates artifacts or it will be direct deployment. So what do you mean by artifacts? So Abhishek, did you understand this one? No question is not, I'm not able to understand. Okay. So Yashpal, this also, if you can ask or simplify it. So Archana, we'll, like Abhishek will be showing a demo on Git, but I think CI CD, we won't be able to. Yes, Yashpal, Capado will be able to identify difference between source and destination org. How to, how do we deploy integration related matter data in settings would be good if we can have some demo. So for integration related matter data items, if you have created something, so I think you can deploy it similar to other matter data items, right? Abhishek, what? So I mean, so I mean, for example, let's say for integration related matter data, you have created a remote site setting, right? So that remote site setting, it will be a manual change in your target org. But if you have created a name credential, name credentials can be deployed with the help of deployment methodologies. Right. So wherever you have matter data item available, you can deploy it. If it is not available, then I think it will be manual deployment. So you need to go to the target org and you can just create it. So next is DevOps and CI CD same. I think kind of. Yeah. So when I will try to have this thing CI CD, but as of now, we have not planned this, but maybe in future. So Prateek Zira is paid tool. And it is, it is J I R A not J W R A, it is J I R A. So I will see like if I will be having any anything on Zira. So if I will be having some free licenses, then I will try. Otherwise I will see like how much it costs. So it depends. I cannot commit. Like I will be having some sessions on that. So Shirini boss is asking how to deactivate triggers in production environment. So someone has already answered this one. If you see the we can we cannot deactivate triggers in production. We have deactivate in lower environments and need to deploy. And as a workaround, I think we can use custom metadata for that, right? Custom metadata types. So through that, we can control this activation and deactivation. So next is how we export import custom metadata, like custom fields and standard fields, not records from one up to another is possible with fork bench. So I think custom metadata. We can deploy. This is this is possible. This is possible with the help of package XML. So in the in the in your package XML, you will be setting up your custom fields name and then you will be retrieving it. And after that, with the help of package workbench only, you can deploy to target out. So that will be we will be having a demo session for this. Okay, so there is one question. Someone is asking about data analyst or business analyst. So I would say like if you can reach out separately to me either through telegram or LinkedIn, so maybe we can have a chat so that we can discuss. So there is one more question. Suppose if I am adding pick list value to opportunity stays field and other team is doing the changes to that field in another sandbox, will it override? Yeah, so whoever will deploy it last, right, it will get overrided by that. Right. So last deployment will be there in the target environment. So LWC is not finished. A few topics are remaining. So I will be covering them after this deployment QA and mock interview sessions. I just need to create some content. Actually, slide decks and examples are not created yet. So that's why I just skip those sessions. So I will be covering them. Okay, so I think with this note, all the questions we have answered. So I just want to thank Abhishek for delivering all the knowledge to the community. And Abhishek will be delivering two more sessions in this week. And as I already showed you, like from next week, Omnis Studio bootcamp will be available in front of you live on this platform. And we will plan that in such a way so that you can have all the concept related information and all the demonstrations as well, and will give you all the exercises as well so that you can practice that. Right. So with this note, I take your leaf. And once again, I want to thank Abhishek. Thank you. Thank you so much for delivering your knowledge. And yep, that's it. Anything that you want to add Abhishek? Thank you so much, Sanjay. Thank you so much, Sanjay for giving me this opportunity. And I'm more than happy to share my knowledge around deployments and velocity of Omnis Studio. So we will be running a velocity bootcamp in a very detailed manner so that each and each and a person who don't know what is Omnis Studio, they can get the full information about it and why we use it. Yeah, exactly. And like the session tracker which I'm managing, people are liking like how things are placed in systematic order. So like we'll be doing all the session live. So those who ever can attend live so they can join them. And those who will be watching the recording. So for them, it will be kind of self-paced learning because in live session, you can ask questions, but in self-paced like if you have questions. So but for that also, we have a solution like telegram group. So if you have if you will be having any questions, so you can ask and help each other so that if you know the answer, you can you can guide other person as well. And I will add Abhishek as well in that group. So as per the time availability, if we see anything that is challenging, so he will also answer those questions. But try to join the session live because Abhishek is also have limited availability. So if you join and ask questions live, so that will be better. Okay, so with this note, we take your leave. Thank you so much for joining this session live. And if you're watching the recording, thank you to you as well. And once again, thank you Abhishek. Okay, bye everyone. Take care. See you tomorrow.