[00:00:00] Welcome to another Xforce Data Summit presentation. Today we have Bash Din, who's managing director at Zumzum, which is a Salesforce app exchange partner, a system integrator, and they make Zumzum financials on Salesforce. And he's going to talk about something that's really important to anybody who's ever been a Salesforce Administrator: Salesforce DX, how to migrate things from your sandbox to production. Here's Bash.
[00:00:39] Great stuff. Thank you very much, Leonard. Well, welcome, everybody. Thanks for joining and tuning in and taking your time to have a look at this presentation. So, I have two parts to it. There's going to be a few slides just to introduce the concept of what Salesforce Developer Experience means to awesome admins.
[00:01:01] So I consider myself an administrator. I'm definitely a clicker, not a coder, so when I first looked at Salesforce Developer Experience, a little bit daunting to think I'm not great at coding. I realized I wasn't great at coding. Left that 30 years ago. Love Salesforce because it's all about point-and-click.
[00:01:20] But some of the benefits to this are super appealing., even as an admin, so I thought, you know, let's start experimenting. What does it mean? And then once you grasp the tools and start to use them, you realize even as an admin with point and click functionality, you can take advantage of the benefits that Salesforce Developer Experience brings.
[00:01:42] And I said, what does it mean to me as a Salesforce administrator. I've got really broad sets of functionality that I need to know about in Salesforce, and I can sort of categorize it, or Salesforce do here in four main categories. And you know that first thing about simple tasks for adding users, removing users, you know, the user interface.
[00:02:08] What do the screens look like? What information do we display to those users? Which means I'm getting down to things like money managing, profiles, and permissions. And we'll talk about how to migrate that from, you know, when you're a new dev org, your development org or your sandbox, and actually moving it to live. And clearly, you know, when I go to my data management, if I'm adding new tables, new fields, I've always got to consider
[00:02:33] you should be able to see that field or edit that field. Are there any validation rules we're going to put around that to control data quality? And again, all of this I can do as an administrator are point-and-click functionality, but also, and I got two balls to juggle, moving from my build environment to either test or live.
[00:02:55] Whether it's a simple field that I'll add on an existing Salesforce object or our own custom objects. You know, even customizing those fields, the ripple effect that has on the system, just the amount of elements that I need to move from a sandbox to live. So, it's a build up quite quickly. And you know, either I'm keeping a manual list or trying to do that from some other kind of tool that helps me to move change sets around,
[00:03:19] so that when I do deploy it, then I respect the organization’s security model, and we’re always, you know, aware of privacy insecurity. And as a Salesforce administrator, yeah, we've got our production org set up. So, when I create a new field, yeah, I can get granular, Dan, as we know, field level security, and quite often I'm deploying change sets.
[00:03:39] And the things that are left behind are things like profiles and permissions and security, because the granular detail, I forgot and I hand it to a bunch of users, and we're like, I just have to do yet another change set to keep moving components either because you know, it lives in so many different places within Salesforce.
[00:03:57] So at the end of the day, you know, in terms of getting that information to the people that need it, reports and dashboards, making sure that the visibility in anything in that build, whether it's reports or dashboards, I can move and we can iterate and keep developing and moving those forward. So, across the board, Salesforce DX is going to help
[00:04:15] administrators as well as developers. So, you know, whether I'm a solo admin and we always have that accidental admin, whether you're the CEO, the business user, the floor Salesforce adopted it because it's so easy and simple to change. Change page layouts, add fields, customize. That you can do that very quickly and you can start to learn how to do this and as the organization grows, your Salesforce environment grows.
[00:04:43] And whether you take on developers full time on your staff or have partners come in to help you and build functionality for you that you can't be through point-and-click, yeah. Maybe through code or special pages or lightning web components. You may either all be working in the same org. And that's been the bottleneck and the huge trouble
[00:05:03] that we've all experienced, especially when something changes by one admin that actually breaks test coverage. Or now a function that a developer's working on. Or you can't move changes from the sandbox of the live system because it's tied in and dependent upon other changes before you actually move yet, so it slows you down.
[00:05:26] You might end up then, you know, creating multiple sandbox orgs and the challenge of trying to keep everybody working on the same, you know, version, that concept of what's the latest version in Salesforce has been, you know, an obscure concept, you know, where is the version of our truth? Which sandbox does it exist in?
[00:05:44] Or in fact, if I'm an accidental admin, and I think we've all been guilty of this, or a case has been reported or request has been made, I've gone ahead and made the change in production. So actually, I'm of the opinion that the production system is the right version of the truth and everything else is out of sync.
[00:06:05] But you know, when you're deploying change sets, the complexities and the issues that are caused by that, you know, slows the organization down. So, whether you're working individually, even individually, that whole concept of what did I change, when did I change it, and how do I move that from you know, my developer environment, my sandbox, to production in a smooth manner and get it right first time?
[00:06:27] So everybody's happy. I don't have to go and do rework. But I can continue to develop more functionality. Now, Salesforce addressed many of these requests from the customers, predominantly, you know, from the developer community. Any developer outside of Salesforce. When you talk about the concept of watch your version control system, where's your source code?
[00:06:51] What's the source code control system check in, checkout, in a basic functionality. The, I think we've all been pining for in the Salesforce environment, even as an administrator, if I have a page layout or a database table, I'd like to know what the current version is and what the changes have been made and by who.
[00:07:09] I'm able to roll back and roll forward as well and move that to a live system. So, the idea of moving away from being tied into an org and being able to have our source code, even considering database tables and page layouts or validation rules, workflow rules, is that’s our source code, and that's where it lives.
[00:07:28] And every time we make a change, we can track that and roll back as we need to. Keep everybody up to date at the same time. So, all built around collaboration, knowing that the world that we live in now, it's probably, yeah Salesforce increased the number of sandboxes everybody can have, so we can all have multiple sandboxes.
[00:07:47] Yeah. They've introduced the new concept of scratch orgs scratch, and we're going to talk about that, which means that we've all benefited from an additional 40 developer roles in Salesforce. So as an administrator, well that's interesting for me, and as long as you're on an enterprise and above, that means we've got a new type of org that we should be taking advantage of.
[00:08:09] That's going to help us to continuously deliver new functionality, you know, whether you’re an app exchange part of development partner and developing packages we're using packages internally or indeed the internal Salesforce admin or Salesforce team that's pushing out new features and function to the organization.
[00:08:28] We want to do that quickly and smoothly in a constant pipeline and be able to, you know, increase our velocity of getting those features out. And then the openness of the platform that Salesforce, although we're going to talk about Visual Studio code, is the, you know, standard tool that Salesforce are showing on Trailhead and all the demos and all the videos and the one to adopt, you know copy and paste.
[00:08:50] It's like a mobile phone. Every developer's going to have their own preference.
[00:08:53] There's a number of tools that support it on the actual desktop. As an admin, obviously I went through Trailhead and said, right, what are they? You know, what are the most important things that I need to know and learn about?
[00:09:06] And you know, Salesforce DX is not one feature. It's not a function, it's not even a tool. It's a whole overarching methodology on Salesforce. It's an umbrella term. It says we are going to move from being tied to develop, developing, and building in orgs to moving to a source code control system. So, in every production org that’s enterprise and above, Salesforce have enabled a developer hub.
[00:09:37] Yeah. Which we're going to use the term dev hub. That’s our core hub. It's your production system, and this is used to control the number of scratch orgs that you can actually create on a daily basis, a number of scratch orgs you can have active. You can do this in Trailhead and you can do it in developer orgs in our test environments.
[00:10:03] The reality is we've got this in our own environment, so everybody with enterprise and above, is we can create up to 80 scratch orgs a day. That means I didn't delete super-fast, and we can always have up to 40 scratch orgs going at any one time. They're limited in life, which means that they default to like seven days.
[00:10:21] And if you don't do anything, they will expire at the end of the life. So, they’re meant to be for a very short life. The maximum you can set it is for 30 days, and after 30 days, the org will be automatically deleted by Salesforce. So, it’s self-cleansing. It develops a really good habit. Create a scratch org. It's either a replica of your sandbox or your live system or a brand-new blank template.
[00:10:46] And if I want to experiment with the new feature or create a new module for our business, and I might just want to blank canvas a standard cell source org that I can actually build in. Or maybe I'm going to take a replica of our sandbox. You can have templates as well they can actually use, but we're going to start with very vanilla at the moment.
[00:11:03] When you follow the help articles and a Trailhead, you'll end up with just a vanilla sandbox. It doesn't necessarily, represent your sandbox org or live org which means there's still a place for some boxes in live orgs, they're not going away. This is not replacing it. This is adding to what you've actually got.
[00:11:22] So if these orgs disappear after a limited amount of time, the source code control system is going to be super important. And you know, the command line, the Salesforce command line interface, the CLI, yeah, it’s obviously very appealing for developers that are comfortable in working in this world. I looked at that and I thought I could copy and paste those terms.
[00:11:46] So look at the manual, perhaps create a scratch org, all the instructions are there. You copy and paste to your command line. And actually, when you work through some of the learning material, Trailhead as an admin, you can follow the concepts. You can start, build, modify, and delete your scratch orgs without being a coder.
[00:12:01] But then obviously the Visual Studio code, the developer tool, is a nice graphical interface on your desktop, Windows or Mac. I looked at that and I realized that many of these commands that have to type in or copy and paste at the command line, I can actually do with keystrokes in Visual Studio code.
[00:12:25] Certainly 80% of the ones that I want to do as an administrator who loves point-and-click, I can take that methodology to the tools here and work out a pattern to make sure I can use that in a point-and-click environment. So, Salesforce developed a bunch of plugins and we'll continue to develop plugins for Visual Studio code.
[00:12:47] VS code, as I might refer to it during the demo or the presentation, I'm going to see that very popular IDE. Salesforce have retired their own developer tool and said, “Move over and this is the one to go for.” But by the way, choose your own. The command line interface will work with many tools, and when we look at the source code control system, again, choose your own version control system.
[00:13:12] We're going to use Git and GitHub because it’s super popular. It's also the one that's in the learning material as well. But again, Salesforce said you were free to choose. You might have one already. So, some people might have had to build this themselves and compensate for the fact that Salesforce didn’t do this. Or if you're starting from scratch, you know, go and buy one that's suitable for your business.
[00:13:32] We are going to show, uh, Git and GitHub. And that's what you're going to see in the learning material as well. So, the new way of working is that we're going to have up to 40 scratch orgs that we could have. I can have multiple scratch orgs myself or a number of people working on their own independent features, and at some stage they'll need to be checked in and merged together in the version control system.
[00:13:56] So we'll be able to have the tracking and visibility in a very granular level. About what's changed and who made that change? Whether we need to roll it back or if you're happy to merge it in, which, you know, a property, a popular practice, this is a branch, you know, a master branch. And then to have a developer branch and other branches as well.
[00:14:16] So even the branch is a disposable. So, if I experiment on a feature and it doesn't pass the, you know, requirements of the business, I don’t want it, I can delete that branch and I've not affected the call code or that master code. This is very different from a sandbox, when I add a function to assemble, to show a concept.
[00:14:35] So let's say I got a request from the business to create a purchase order system. And I go to the sandbox and I show them that and they say, nah, that doesn't do what we want. It's all right. Thanks. No thanks. I'm not left to unpick everything I want from a sandbox. And of course in this concept of having an independent branch where you can build modules or experiment if the experiment works, merge it into the master code. If it does not, delete, forget, I didn't bother anybody else or trip them up or put code in there that, you know what I'm saying?
[00:15:05] Function, the database table. We're going to create a purchase order module. I don't want that to leak out into the application when it's actually not been adopted. So even branches like scratch orgs are disposable, you can create and dispose of them as you want. So even if you just took that concept of taking your production code, moving it to your source code control system, and then being able to pull a copy of that,
[00:15:28] in an independent branch, develop some ideas, either check that in or dispose of it, and if you check it in and you like it, merging that into your master system. Being able to deploy that to your sandboxes in production org, you know, so of course there's still a place, for some boxes, you know, for, you know, large amounts of volume, user acceptance testing, integration testing, how's it really going to work?
[00:15:53] So, you know, it might well be that scratch orgs are just vanilla. We have the module and then later on we see what, how it really behaves in user acceptance testing. And again, once we're happy or we can iron out bugs. Even there, we can be fixing and changing from the source code to sandboxes. So, Salesforce, with all of this environment, including pushing it to your production system. The entry level for an administrator is to work through these on a manual step by step basis.
[00:16:22] But the vision will be that much of this will become automated and using things like packages. So already Salesforce are asking us to start thinking about our org in a more modular approach. You know, we have the base package, everything that's included in Salesforce. We've customized certain elements of that.
[00:16:41] You know, if we created new fields on the account screen, we have an account module. If we developed a sales invoice or a purchase invoice, you know, we have a purchase invoice module and now we can break those down into separate containers called packages. So, we'll start to deploy and handle and manage versions of packages.
[00:16:59] So that's quite a journey to move from having a dev org having a sandbox and move a change that's live, because that's what we're doing as admins right now right now and Salesforce will map that journey out for us, you know, so we're right here at the beginning, understanding that I'm building apps as an administrator to respond to the business.
[00:17:20] I'm finding spreadsheets or home grownups. It might've been on desktop, internal databases and say, hey, let's move that to Salesforce so it can be micro apps or larger enterprise apps, building those up. So as administrators, we're actually up builders and there's going to be an increase of citizen developers.
[00:17:40] A huge amount, you know, 500 million apps are going to be launched in the next five, 10 years according to the numbers. And it keeps changing. And as we said, Salesforce is super powerful. It's an easy developer environment. Even citizens, users, CEO, CFO, CIO, could be building apps on Salesforce. Of course, there's a, you know, an introduction to understanding the design, build, test, deployment of apps. Follow the trail.
[00:18:05] This is the URL here, a couple of URLs. And I want to just show the general getting started with Salesforce DX, and then, you know, looking at that with my administrator eyes, of course, I want to understand how to manage my app. How to help users adopt those. We change management. There's some small, basic, projects to do on like GitHub. Get yourself a GitHub account. Fairly straightforward. How do I actually create myself a GitHub repository where we can deposit our source code, use Trailhead, and create playgrounds, experiment with it. When you feel confident, you'll go to your production orgs, start to turn on these features or practice, follow that, and we're going to stick at these first two entry level.
[00:18:52] You know, how do I get myself a GitHub account? How do I get some source coding control in there? There are some advanced tools to take your existing source code and convert those from one format and the traditional metadata format that Salesforce is used to, to now a source driven. You'll see that from much further up in terms of getting yourself in a mindset of thinking about your org as modules, putting those into containers as packages and converting those and putting those into your source code.
[00:19:21] So as you start to get further up the rum, you are going to find yourself, your skill set increasing and there are still unfortunately some functions that are limited to command line, typing in commands or copying and pasting. By that time, you'll be comfortable with the environment and tool. You build up a library of the most regular
[00:19:40] 10 commands that you're using and you're copying and pasting in. This is how most of our admins, developers are still memorizing and typing it out with auto-suggestion. Fabulous. They do that every day. Or admins, what we found was that build themselves a doc or is an intranet with the 10 most common commands.
[00:19:58] And then using the 10 most common commands regularly, you can copy and paste. Only those that I can't achieve through the point and click tools on Visual Studio code, so that now this generally will get you the command line installed on your desktop. I'm going to show you that today. So, I've already gone ahead and installed the command line into place.
[00:20:14] I've installed the GitHub client, installed Visual Studio code. I've installed the plugins, so that's fine. The first couple of badges will get you there and running. And then we’re going to take a little look. And a couple of examples of, you know, how I decided to show off Salesforce DX to administrators. So, I'm going to go off to a little org here.
[00:20:43] So dev hub is an interesting concept. So, this would be inside our production org. You're not going to see these two tabs. What I would suggest, you know, is create a micro app called dev hub. Add these two folders into this, sorry, these two tabs into there. You're going to see active scratch orgs and scratch org info. And this will only become available when I go to the setup in Salesforce, and regardless of the interface you're actually using. . .
[00:21:19] Sorry, Symantec locked me out.
[00:21:30] Wow. Right.
[00:21:38] Sorry, just logging back in again. So, this is a demo org that I've got. It's like a production org. I log in as an admin, so it's taking me directly to set up. I'm going to search for dev hub. It's one of those features that once you enable, you won't be able to disable it again. So read the disclaimer there.
[00:22:02] I've obviously gone ahead and enabled it. So, this is the org where I have to have permission and anybody else that's going to be able to create scratch orgs in your environment needs to have permissions and licenses on your dev hub. So, it's a way of controlling that. And Salesforce being very generous,
[00:22:11] they'll even give you extra licenses for people that don't have a full-blown Salesforce licensing. So, you know, that's just your developers, your partners, et cetera, that you want them to create orgs under your environment, you switch on the dev hub. Of course, there's some optional extras that I haven't switched on right yet.
[00:22:37] At some stage in your journey, you're going to say, right, I've got this concept. I've got my source code. Yes, I'm going to create a package, start moving a package around, and you'll be able to enable unlocked packages. So, there's two types of packages: Those that every customer will be able to use, and of course there's always a customer, and have been for many decades now, I think.
[00:22:58] And also where a developer that lists an app on the AppExchange comes in financials, all accounting] applications. So, there's two types of packages. The customer, we’re interested in unlocked packages, right? Somewhere along our journey, there's a budget on Trailhead, unlocked packages. Test it in your Trailhead environment, do it in a dev org, and then when you're comfortable come and switch it on, and then you'll work through the badge in your real-life org and you'll get your modules into their own discrete packages.
[00:23:24] But obviously we need to be thinking about what those packages are going to be. More than just don't put everything in a single package. And definitely don't do that right now. And then as you learn about what's your base package and those that you add on, you may try it on unlocked packages So, affecting me then what that does,
[00:23:41] is enable these two tabs, your active scratch orgs and the information about the scratch org in just our production. So here in the demo org, obviously we've got a bunch of different apps. The two tabs that you can search, right now, I'm just going to say there’s one and we're going to see that when I go to the command line, unfortunately at the moment and what I’d really like is a button here that would say create scratch org.
[00:24:05] Not quite there, but I can see, listen, thinking, yeah, you know, I've asked the product management and the, I'm an admin can I click a button, create a scratch org here, and the answer is not yet. Nice idea. I'm wondering when that would be available to make life easier, but I didn't want to wait as an administrator and said, okay, I'm going to get familiar with this concept. Being able to add and remove scratch org apps.
[00:24:29] So we've gone ahead and enabled it. Obviously we haven't got much in there. The other tool that we said that we would install, I've got visual Studio code installed and when I click it, and a lot of the material is about going to the command line, and of course I did follow the train and went through the term and all in either type the commands or actually copied and pasted them from the documentation or from Trailhead.
[00:24:59] And then, Visual Studio code is a nice container. There's a command line included in the container as well. So just put everything into a simple interface for me, and I thought, yeah, that's nice. I don't have to interact with multiple apps. When I do need to switch to the command line, I'll be able to actually do that directly in Visual Studio code.
[00:25:18] And then when you follow the documentation more than Trailhead, when you realize you can go command-shift-P and a menu will appear of a whole heap of commands that will perform Salesforce DX commands for you, and also GitHub commands for you. So, I don't have to actually memorize, but I recognize them. I’m doing point-and-click, and the command line is being fed the commands.
[00:25:44] And that's because we've got a range of, plugins installed.
[00:25:54] You can see we've already installed this, some extra ad-ons, the GitHub plugins, the Salesforce plugins. When you install it and you set up your environment, you'll get all of those in. And these tools allow us to do things like create a project. And if I follow the documentation, it'll ask me to point and click.
[00:26:12] But here, it asked me to use the command line. Here, I can actually just go ahead and create a Salesforce DX project. It's gone ahead and activated my extensions and the dialogue is asking me what kind of Salesforce DX project do you want to create? You know, a standard project, or do you want an empty shell?
[00:26:34] And if I'm an advanced developer and say, I want to do my own thing, then here's an empty shell, standard. We build a template for you as you'd expect it for Salesforce, and then you can commit it to your GitHub. Would you want to do something with analytics? Now you can build analytics packages and templates and dispatch those around.
[00:26:51] But I'm just going to go ahead and say, build a standard project. Give it a name. Let's call it purchase order. Where do you want to store that project? I'm just going to go ahead and put it on my desktop at the moment. I mean, I recommend create a folder with your various, projects. Here you’re going to contain two things:
[00:27:09] Obviously it's the link to your source code control system. I'm just going to get rid of the welcome screen on the right-hand side. And as we expand on the left-hand side, Salesforce has built the container. They've also included a couple of files that are super important for GitHub as well. So, when we go to GitHub to create our repository, we want to make sure we're going to do it blank. So, for example, there's a read me file. You'll see that when we try and create a repository in GitHub, so, right, we want to put this in repository. Number one, I want to backup. I want to sync. If I've got work in progress and this desktop dies, I want to be able to move to another desktop and install my tools, and away I go. Cool.
[00:27:54] I need a backup. And this is the easiest way. Even working with the old. As an administrator, I worked with the Salesforce IDE plugins for eclipse. That concept of backup is that manual export, a manual zip file, and put it in your cloud storage that we store in is going to be a pain. So just the idea of this, we want to synchronize this to GitHub.
[00:28:14] And there are files that we don't want to synchronize to GitHub. And Salesforce very kindly automatically build, and they were just looking at the text representations, automatically builds all the files that you don't need to worry about tracking, and we can add to this as we work in along, you know, there's going to be some components that will come out of our scratch orgs.
[00:28:36] And I said, I'm not interested in tracking that. That's a standard field in Salesforce. I don't need to worry about that. Whenever I build Salesforce, that's always there. Just my own customizations, what I’ve actually built. And there's a structure here that we'll see that the app that we actually have, you know, whether it's the apps that we see on the screen, or like my dev hub, or whether it's all your various objects and page layouts or code or triggers or lightning web components, here’s where it's going to get stored in a hierarchical structure down to the metadata files in XML format or any other format.
[00:29:13] And where you going to synchronize that? And this is very lightweight and this is what we're moving around. So, the idea of being able to visualize my object as a flat file and say that's what actually creates it. And then compare those on the screen as well. I haven't gone ahead and creating any default org yet.
[00:29:30] So at this stage, I might go off to GitHub and say I'm just going to create myself a repository.
[00:29:38] I switched to my browser. When I create a GitHub account, I'm going to mark my repositories as private. There is a special offer from Salesforce and GitHub that will get you a business account for up to five users free of charge. Yeah. If I'm any developer, any admin, I can go and create it, GitHub accountant, have a private repository
[00:30:09] with some limited functionality free of charge. I don't want to expose it to the rest of the world, you know, it's a profile. Of course, we run our app through there as well. So, it's a collaborative environment that we can all look at, features and functions that we're checking in committee. So, under my repositories, and I've actually got a few repositories or repos. See here, we've got the purchase invoice or the sales invoice, repository, or a demo.
[00:30:41] I'm just going to move this screen out of the way so I can say, I'm just going to go ahead and create a new repository. Because I'm working on a module called purchase order.
[00:31:00] Remember to set it to be private. And even when you’re in a team and collaborate, I mean this, it's secure. You can implement two factor authentication and secure your code. Yeah. And do, you can obviously invite users into your repositories to collaborate in a secure environment. This here you can see
[00:31:19] I’ve deselected in my world, that's the one gotcha. So, when we’re creating a Salesforce DX repository, make sure you avoid creating the read me file because the next steps will not work. You notice that when I created my project on visual CDA, read me file got put that into this repository anyway. So, I want it blank.
[00:31:40] I don't want any Git ignore or anything else on there. It's a complete shell. Create my repository.
[00:31:51] And that's the container and that's where I'm going to sync my project. Notice the URL. Great thing about Git, GitHub, it's web based and we can link to URL. So, it's going to recognize this is the address of your repository. Obviously there's more advanced tools, through secure SSH. However, I'm a point-and-click click admin, I'm going to remember this URL, and that's how we're going to identify
[00:32:20] our different repositories and GitHub that when we'd clone it, it'll ask it, give me the URL, the web link to where the repository actually links. It's going to bring a copy down to my computer, so it's a bit like cloud storage. There's a copy on the cloud in GitHub. There's a copy of my desktop and the two will be synchronized.
[00:32:39] I recommend doing it manually because I'm committing changes. And when I'm happy with a change, send it to GitHub. And then when I'm on changes, bring them down, and I'll manage when I want to do that. Of course, you can be super advanced and have it synchronizing all the time as well. You know, choose a way that actually works for you.
[00:32:56] So when we look at this empty container at the moment, nothing in there.
[00:33:02] A couple of other things that I would do at this stage: So we've just got an empty shell and I'm going to in a moment create a scratch org and go into that scratch org and develop a new module. But I'm going to initialize. And it's auto-suggesting you read the manuals and the documentation. It says, “Hey, type this command on the GitHub command line to initialize your repository.”
[00:33:29] Whereas I see here I can go command-shift and P, type the menu and the menu has been suggested. So, initializing a repository is basically saying create an empty repository here on my computer.
[00:33:46] Where do I actually want to put this repository, you know, the project that we've created, purchase order that’s saved on my desktop? I want a repository in there. So, it's asking me to choose, and I don't have to worry about typing the whole path. It's already said, “Hey, is this the one that you want?” Because it's the project that I'm working in.
[00:34:06] Yes, that's what I want. You'll notice that it's already detected there were 15 changes on your desktop. You haven't added them or checked them in to GitHub yet, and you haven't actually published your repositories. Everything's here locally. So, one of the last steps that I'm going to do is I'm actually going to say, well, I've already got the repos.
[00:34:29] So the order of events is ensuring you create a blank repository on GitHub, and then you come to Visual Studio code coding, create your repository, and we're going to link the two together and say, actually, this one already exists, right?
[00:34:47] It's a command-shift, and P. I love the alternate suggestion. It’s using my regular commands, it’s already coming up here. If I don't know any command and I start typing Salesforce DX, you know, it gives me a whole list of functions, and I hope Salesforce will build that out. As I say, it's still limited.
[00:35:07] There's certain things that I realize I've tried to do. I went to the manual. I couldn't find the menu option to do that. So, I did copy and paste to the actual command line. But what I actually want to do here, go back, I want to add my remote repository. So, I've created an empty shell here called the GitHub repository.
[00:35:30] I'm actually going to synchronize it to a remote repository, and we call that remote repository purchase order. It says, “Now give me the web link where that repository already exists,” which just to make sure I copied it, double check, copy, paste, done.
[00:35:57] We've now linked the two together. And here you can see that now we have an option to synchronize the repository. Now just a little bit about this Visual CDA coding environment.
[00:36:17] It's a bunch of tools on the left-hand side as well. We're not going to go through all of them as well. Notice right at the top for the time that I need to switch to the command line. I can begin a new terminal session, and it's just a window inside Visual Studio case. I like the idea that I didn't even have to leave Visual CDA code.
[00:36:12] I said, “How much could I do in this one hour on the desktop that Salesforce are recommending and thousands and millions of developers are using around the world? Oh, it's got an integrated terminal. It's the command line interface, you know if I type in SFDX.”
[00:36:57] You were told, go install a command line on your windows or your Mac and type these terminal commands in. I can see here there's a bunch of commands as well, and I don't know if I can go SFDX. . .
[00:37:18] Excuse my typing.
[00:37:25] Oh, I see what I did wrong there. Sorry. SFDX. Yup. So, look at the screen while I'm typing as well, and you can drill into further on SFDX help about plugins, SFDX help about, give me a list of all the commands. So yes, I've got the documentation pinned to the browser page, but realizing that there were like 10 popular ones I'm using regularly,
[00:37:46] I've got them in a word doc, in my Google doc. I can go back to them to them regularly. Of course, you start to memorize what some of these things actually are. If I wanted to, I could even switch to which terminal do I actually want to see? I can see the command line, the Salesforce CLI, the GitHub CLI, and it's all happening here, within that single environment. Now, I’m going to move this.
[00:38:14] I'm just going to close a couple of these files over here, which you can to avoid distraction. So, looking at, GitHub, we’ve created a new project. We haven't actually done anything in Salesforce yet, and it said, you've got these 15 files that have not been checked in or committed to GitHub. Do you want to add those in?
[00:38:45] I'm going to put myself a message so I remember what did I actually check in. I can review individually, and this is what's going on, on the right-hand side. If I choose to have a look at forceignore, a Salesforce file, this belt, as a template, for you to identify those things that you shouldn't be tracking and checking in it.
[00:39:10] Because they’re system files, you don't need to worry about those. Every time you set up a project, some of these will be created. So, in fact, ignore those, you know, so Salesforce, builds that in your template. What season? Again, we can add other elements to it. I want to take you through all of them, but if I want to individually review and add it,
[00:39:29] I can add it or I can reject it individually as a list. I'm just going to go ahead and, add all of those 15 in, so it's now saying it's staged, and once I'm happy I'm going to do a local commit. What local commit is saying, “Hard save these to my local repository. I'm happy with the changes.”
[00:39:50] That's my anchor point. If I fail, I've always got that roll back. Go ahead and hard commit and save it to my local repository. So, I've now got an option to send the changes up to GitHub. I'm going to go ahead and publish it. Now we've created the link and the relationship. I've now put a copy on there.
[00:40:16] Well, if the machine dies at this point, that's my roll back position. If we come back to our GitHub repository, we can see all the files that we had. It has already been created, including that read me file that we said don't build your own because that'll cause conflicts and stop it from creating. It's all been created.
[00:40:37] Okay. Let's. . . a good practice on my source code, I'm actually going to create a copy of this now just to demonstrate. I know I haven't put anything into here, but I'm going to create a developer branch and I'm actually going to create a feature branch as well. So, this is all stable code. We're now going to have an experimental branch where we know it's not all working correctly, becauseit's development.
[00:41:06] And then I'm going to have a real experimental branch called a feature branch and it tends to be not three model or master of stable code. We could push the production at any time. That's always working. That's the goal. Everything in development is approved QA, but not quite ready to merge into our source code.
[00:41:24] So we can do a couple of things and there's a nice little gem of a tool that comes from GitHub. Normally I would copy and paste this and tell my command line to open the repository and use command line tools to create copies. Yeah. There's an even easier way. So, I've installed an additional app that you'll find on GitHub called GitHub Desktop, Windows or Mac graphical user interface.
[00:41:56] It's a nice way.
[00:42:01] Oh, lovely. It’s saying, that's true. This already exists on your desktop. I'm not going to clone it, so thank you very much. Already managing the conflict for me, it says this repository exists. Choose it. So, we just have to alert GitHub desktop that our repository is here, and from here I found a tool that allows me to browse my GitHub repositories, but more importantly, with a point-and-click interface, be able to create a new branch. I'm going to call it develop.
[00:42:51] I'm going to take a copy of master. Let's go ahead and create that branch, and similarly, a point-and-click tool that says, “Let's go and publish that.” I create a replica of our source code. And when it's finished publishing that. . . and the two work in tandem, if I make changes in Visual Studio code they’re tracked, they're also tracked in my desktop tool.
[00:43:15] I can use either tool to manage and update. And both of these are being synchronized, but it's talking to the same repository on my computer. So, if I now switch to the web interface, previously we had one branch. Now I've got my master repository. Cool. Safe. Nothing wrong in there, no bugs, a belt to developer branch.
[00:43:36] We're going to use that to check in our changes. So therefore, I'm going to create yet another branch to start experimenting with a new feature. So, let's go new branch.
[00:43:49] So that's the advice. Naming convention, you know, come up with your own naming convention, you know, feature slash that means it's work in progress. Master. Everyone will know that's your master develop, the unstable work in progress, and feature all experiments, features, anything they're actually working on.
[00:44:08] So let's go ahead and call it, in fact, new.
[00:44:18] So I've not created it before. I want to create a new purchase order. I'm actually going to create a clone of the develop branch now. Yup. Let me just move the meeting window out of the way. Okay, great branch. And we'll just go ahead and publish that as well.
[00:44:41] Now, actually this is the branch that I'm going to work on, so I'm going to go away. I can close.
[00:44:52] The other project that I actually created, this time, I'm going to go back and I was working in my repository both different ways. I can open it in Visual Studio code or directly here, I can say repository open in Visual Studio code or your preferred IDE, your developer environment, and this is open that.
[00:45:14] And we're going to synchronizing it. This time though, what we'll actually do is we'll move forward now and say, I don’t actually have one of these scratch orgs created, and like in command-shift and P, or control-shift and P, I can see the option for create, or if I was typing create, it's going to also suggest the various functions.
[00:45:37] I can SFDX. Whether I'm creating, you know, another kind of file. I want to create a default scratch org before I do that.
[00:45:55] Nope, let's do that.
[00:46:05] I'm going to need to authorize my dev hub. A request is going to go to our dev hub that we showed earlier on to say this is the authenticated user. Are they authorized to create scratch forms on our behalf? Yes or no? Yes. What's our daily allowance? How many have we got? What's the template that we're going to use to build that?
[00:46:24] I'm just going to go ahead. It's a web flow. It’s Oauth open authentication. A browser window is going to pop up and say, “Please log into your dev hub.” Luckily I'm already logged in, so it gives me the green light. Depending on what your set self is, you're going to need to use username, password. If you're already logged in, it'll show you.
[00:46:45] The user will go directly to that org, say, thank you, you've authenticated. You can now close that browser window. So, when I go back, it says it's run completely. I thought to hide away these messages. If I really want to, I can go show me the outputs. Let me just resize these windows so we can bring that to our attention. And what it’s very nicely done for me, a whole idea of typing a command into the command line. Obviously the project. Click function and add it into the command line. Relatively short one SFDX force:auth. You know, you start to learn these, but when you use them regularly, obviously moving to point-and-click, say right now I recognize it.
[00:47:39] Well, what I want to do is creates a default scratch org.
[00:47:50] One of the parameters we would normally send to the command line is what's the template of the scratch org, what's it going to look like? I want to show you all the details in there. We're using the standard template, point-and-click, say, this one is one that was included in our project when we created it, but you can tailor all of that.
[00:48:10] What do you want to call this scratch org. You're going to have lots of them. So given a name that you're going to recognize it rather than a username. So, let's call it
[00:48:21] new purchase order. How long do you want the scratch org to last? It defaults to seven days. I could have it today, I can create and delete them on demand within a few minutes. We're going to see this within 60 seconds. Create a new scratch org for if you’ve ever tried to create a sandbox and you've waited for your sandbox to be created,
[00:48:43] you've waited for your sandbox to be activated, then, you know, moving from idea to prototyping, the time is shrunk. Just having an environment that you can actually spin off almost immediately. I'm going to leave it to the seven days, let's say, let's use the default, and now it's running the command line instructions for me and going into my dev hub authorizing me, creating an instruction, spinning up a new org, and the new org is available.
[00:49:18] And we can see where it connected. The little icon. There is a command line instruction, I know, to open my default scratch org, but that pointing-and-clicking saved me remembering all of those values, which of course I can copy and paste to my own manual and use it every time. But again, it's automated all of that for me.
[00:49:40] I can do it through a point-and-click interface, click a button. And what it’s going to do is log me in and anybody who's had an issue logging into sandboxes, trying to remember what their username is, password is, you created a new one from live, guess what you are? Email address is obfuscated. It's not going to work.
[00:49:58] You can't do password reset. What was it? And actually, you have a full environment here. I can reset passwords, but one of the benefits, just clicking the URL, I logged into this org, a scratch org, which for all intents and purposes looks like the developer role. Which it is. We've created a standard developer org.
[00:50:18] So I go back to my dev hub and I refresh. Let me just move that out of the way.
[00:50:26] We see a new one’s arrived in the list. This was the date it was created. If I drill into it, it’s showing me a summary, you know? So, in terms of managing as our team grows or the environment grows, behind the scenes there is a file, a scratch org request file. If you delete that, the scratch org will go away.
[00:50:51] You can also delete it from the command line, so if it was an experiment in the last an hour, you can spin up an org, do your experiment, and delete it, and it's gone. Within the limits that I can do 80 to 200 or whatever it is within our license. This is the date it's going to expire. And when it gets deleted, it will track who deleted it.
[00:51:10] We can also configure it with various features. That's done through the project files, actually locally, but I can still see and come up with this idea what's our classic template that we want that reflects our production org, but if we don't have one and want to experiment with Einstein analytics, hey, just create me a default Einstein analytics org.
[00:51:28] It doesn't have to be a replica of our sandbox. Actually, you get an access to features that don't exist in your production org or your sandbox. You can try them out and experiment and really visualize that and show business users without spending the money on any additional licenses from Salesforce. So that's extremely valuable.
[00:51:48] Now take advantage of that. I do have a username. It doesn't show you your password. Use your password management tool to manage your password. So, I'd gone into the browser and logged into my scratch org. I'm just going to go in and you will see a whole heap of objects and functions switched on.
[00:52:08] You can turn them on or off as well. If you want particular functions and communities on or off, chapter on or off, quotes on or off, and you build up your profile as that will be our standard template, but we’ve just gone with the vanilla one and you're going to start to see objects that you've probably never seen in your production org
[00:52:27] and didn't realize they existed cause you're getting a whole week of functionality from Salesforce. I'm just going to check if we got a purchase order. No. So obviously I'm in my scratch org. I know because I can detect that based on my ID. Let’s just make sure there wasn't anything else. We got a few branches. . .
[00:52:55] I think I'm just going to go ahead and say create a new object.
[00:53:02] So a business would like to have the idea of purchase orders and requests and approvals and an automation through Salesforce. Could this be something we could build? We have in Excel, we had it in a desktop app internally or use bits of paper. Could we digitize it? Could we migrate it. Yeah. Whether we build from scratch or use, you know, the tools that Salesforce is helping you with, you know, spreadsheet migration.
[00:53:28] I'm just going to say, well, actually, I can spin this up and get a prototype going fairly quickly, so let's go purchase order.
[00:53:40] I'm just typing some default values. I am going to manipulate the field here because I want the purchase order numbers to be automatically generated. By the way, in case I forget, I want a tab created for this as well, so we're going to purchase orders, tap to go to as well. We want it to have reports. Do we want activity here?
[00:54:01] We might be able to email and store email and communication next to that. And we'll probably want to track field history as well. You know, all features that you would decide on when you're building out. Let's go and get that number, and say,
[00:54:20] Let’s use this simple copy and paste and I'm actually going to call it PO, and our starting number's going to be 1000. So, don't have to start from zero. I'm just going to default it and go save.
[00:54:40] I'm just going to add a random icon. I think there's one down here – shopping cart. Let's just go ahead and add that. Go next. And this is everything that a Salesforce admin does on every single day. So, I'm just going to go through and leave that by default in terms of who can see it. I'm not going to add it to any of the apps right now.
[00:55:04] I'm going to go save, create our object, create our tab. We’ve they actually granted permission to certain profiles as well. You know, a lot of things that we forget accidentally. I've updated some profiles. We'll just go next. Next, I'm just going to add one field, just so we have something to check and track.
[00:55:27] When we’re checking in, I'm going to do a lookup. Of course, the lookup would be to supply our account. And through the wizard, again, I'm doing several things. I'm creating a field. I'm adding in description to the field,
[00:55:58] settings all the way down to a granular level. We're going to see, even on this field, the constraint that we've set is if we've got a purchase order linked to an account, do not let the account be deleted. Try to migrate that to a live system as well. That's the kind of thing that I'm going to forget Until later on.
[00:56:15] So I've deliberately made a tiny little change, so we know the source code is actually going to track it. And go next. And as you'd expect, yeah. Who can actually see? We’re down to a field level, remember those four core things, right? Over in the third one it said field level visibility. We don't realize that we've gone over to security.
[00:56:35] Who should be able to see this? Well, I'm doing as experiment is just leaving the defaults. What about a page layout? Yes. We're going to need to add the page layout. Which account pages will we need to add this purchase order to, as well. I'm just going to leave it by default and go save.
[00:57:01] Well, if that's what we wanted, I'm wondering how many components I need to track for my change sets, and I write them down. The probability that I've done it after I'm too busy building and I'll go back and try and write them down and remember what did I do? So right now, that's it. I'm going to go back to my Visual Studio code.
[00:57:21] They're all command line interfaces, but I'm going to use the menu to say pull. And I'm going to bring down changes. There's a push and pull. I can make changes in Visual Studio code and push them, or I can go pull them from my default scratch org. By the way, you can have multiple orgs. You can be pushing and pulling from sandboxes
[00:57:47] scratch orgs, and have multiple orgs connected at the same time as well, but we're just going to use one. Similarly, we say, great, show me the command that you ran and the result. So, this is what the manual will say. So, we opened the org and then I run a command. I said, get all the source code down. It says, great,
[00:58:13] these are the components that we found that have changed. Well, I've got my notification that the source code control system, it told us that it detected we made a number of changes. There's one of these that I definitely don't want to track because it's the admin profile that's a vanilla Salesforce one.
[00:58:36] You know, when I create an org, it gives you that one. Actually, that's not a good thing to track. I should be using permission sets, or custom profile, which are not created yet. So, scanning down here, I can do two things. Number one, ignore it, and add it to get ignored. So, whenever I make changes, ignore this file.
[00:58:54] I don't really want to think about it. Or completely delete it. I'm just going to delete that file and say never track it for me. Don't even ignore it, but just never track. I can scan through the others and even drill into the field. And you can see everything's highlighted as green because here's the metadata about the field that we created, and I deliberately entered in values here because I wanted to, I could also change the values here.
[00:59:09] So when I'm reviewing changes, the developers are checking in and admins and I'm finding a typo. I don't have to worry about going to the sandbox and saying, “Oh, that's a change I've made right now. That should be a capital S,” and if I want to again detect the change here and notify me, I can go file, save.
[00:59:53] I can push and pull so I can work right here and realize, and you'll notice the same is true in GitHub. Great. I can review all of those, but I'm not going to review anymore. I can check them in individually or as we did before. I'm going to add in all eight and call it new purchase order.
[01:00:24] Add it. Commit that to my local repository. Bear in mind though, that's still only sitting on my computer. So, another indicator in Visual Studio code, I have one change that I've not sent to the server. If the same is true and one of my colleagues has made a change and sent it to GitHub, it will tell me, “Hey, there's a change on GitHub that you need to bring down.”
[01:00:50] I like to be in control and see that visually, manually before I merged to avoid accident. When hyper confident, then you can set it up to automatically, keep all of that in synchronization. Well, I can see there's no changes to come down, but I should be sending a change to GitHub and saying, great, I've now got that synchronized so
[01:01:12] if I got called off to an emergency and the scratch org expires, or my desktop dies, or maybe I get sent home because of a lockdown and I've got to work from a different computer at home, now the ability that I can actually do my setup and get access to this from anywhere, I can now revisit my GitHub.
[01:01:38] Move this out of the way. So, I'm just going to refresh to show that we now have three branches. The new experiment that we're actually working on, the new purchase order branch is telling me who committed one minute ago. I can compare it to the dev org, to the dev branch, and the master branch, and if I know I'm ready
[01:02:09] to check this in, that's my basic purchase order object created, and that's what the boss wanted. I've shown him and he says, I'm happy. Check that in, please. So not only can I compare to both the master and the develop branch, I'm going to say I want to check that into developed, because it's not finished. I know you're not going to be able to create a purchase order and save, and there's more work that we're going to need to do.
[01:02:36] But they said this bit, thanks very much. That. As delivered. That user story, go ahead and check that in. So, keep checking in function. I don't have to wait until the whole thing. The advice is commit regularly. Sync regularly. How often you do pull requests will be your own development teams’ decisions. And notice,
[01:02:34] what it's saying is, “Hey, there’s eight files that have been added.” They’re the same files. I can review them individually. Make changes here. Check those. Do QA review, and if I'm happy, say yeah, so this is me as the admin or one of your colleagues ready to check in and say, credit my pool requests. We’ll get checked in, and when that gets merged,
[01:03:24] then there's a whole history and an audit trail down to an individual file level. So, we see that I've got like one check in. I'm just going to go ahead and cheat. And say merge, pull requests. Merging. It could be a bunch of QA. You could pull that and pull it to another scratch org. And what's happening is when you check it in, I can pull it, I'm doing another scratch org because what we find is that modules and functions work on the developer's desktop.
[01:03:54] Of course, all the dependencies are there. They're working, they’re sandbox, of course they do. When you move it to live and it doesn't work, because they inherited a dependency that only on the developer environments, I can now take this and push it to another scratch org and test it if I want to as well. So however you build your QA process., if I wanted to go to my scratch org and let's say finally make another change.
[01:04:28] I forgot to add a description to the object. So, I'm going the long way round. I've got the window open here. If we go to the details of the actual objects, I should put a description in
[01:04:55] and we're just going to go ahead and make that one change, therefore I can.
[01:05:00] I can push and pull changes. One of the things that I might want to do is just push my source. I made a local change on my repository and I'm not convinced that it went to my scratch org. So, this is what we're doing here. Anything I made here in Visual Studio code or was made it GitHub, brought it down to my local, and I'm going to push it to my scratch org so I can see it in the org.
[01:05:38] And then do it the other way round as well. I can actually pull changes from my scratch org to my local repository. So, I can both make changes here and GitHub or in a scratch org or any other scratch org and get them synced to our cool GitHub repository. We noticed there are a couple of changes made. I'm going to fast track through this,
[01:06:01] Say objects description. I'm going to commit it because they were the changes that we made in our scratch org. Push. Make sure it gets synchronized up to Git. All happening relatively quickly. Obviously the faster you, sorry. The more you work with it, the more repetition you'll have, the more confident you'll get. I can go to my
[01:06:28] develop branch because I've made yet another change in my development branch. And say, I want to do a new pull request. And I'm going to merge it in from my purchase order to my develop. Great tool to compare. One of the actual differences. And I can see that two files were changed. I didn't make any deletions.
[01:06:54] You'll see deletion, so actually the object already exists, but there was one change made, a description was updated. Actually, we do have a deletion. So, I'd already put supplier in, and it's reverted that again. I can edit and modify directly here. I won't. I'll take those and say, I'm going to check those in.
[01:07:18] I created a new request to merge that into develop that time, updated it. If I realized that was a mistake, I could forget it and go back and work in my scratch org without causing damage. I’ve accidentally done that in the sandbox. I'll have to go back and undo work. A nice thing at this stage. That's quite a lot of content to take in.
[01:07:49] I'm sure if we were live, we could take some Q&A or questions or anything, but thank you very much for watching.
[01:07:58] Okay. Got a couple of questions, Bash. I know this took a while, but you're right. It is a lot of content and it's super important too. The obvious question is, can you do this with everything in Salesforce? Is there a list of limitations that makes this hard for an administrator to use?
[01:08:15] There are limitations. There are limitations. Indeed. Indeed. So, it’s just like working with an application program as interface API. So yes, the Salesforce command line interface. It's a combination, though. There are some limits through the metadata API.
[01:08:31] So what they should do, Leonard, is using the metadata API, which doesn't support everything. So, when you try execute it through the command line, you are constrained by much of the same limits. So yes, there are two documentations to chapter what metadata commands actually exist and certain things you couldn't do through the metadata API. And the same is true with the command line
[01:08:53] But the meat and potatoes of Salesforce administration, creating custom objects, creating new fields and standard objects, changing permissions, profiles, things like that. That's all that all can be done through this, right?
[01:09:07] That can all be done. Yeah.
[01:09:09] Okay. So, so that's good. And just to say I pushed something into Salesforce and I didn't like it. Is there a rollback? Can I take that app out? Now that I packaged it up on an app, I assume I can just take that app back out right. Or, or is that not the case?
[01:09:27] Where you are on that journey, that ascent to the top spot on Leonard, you'll have versions of packages in your live version.
[01:09:35] All better, moving the versions is I've installed the version, or a bug’s leaked into production, revert to previous version indeed. If you just use the demo that I showed you. No, it's not easy.
Right?
You still have to use things like, you know, the destructive XML file to remove content from the actual metadata, but when you move to packages, you'll be able to switch versions, say, “Uh-oh, I've updated that version,” roll back to a previous version.
[01:10:03] And if I'm a, I'm an administrator, just thinking about getting started with this, yes, there's free versions of everything you use, right. VS code. I don't have to buy the virtual version. To use that I can get a free GitHub account. I can basically, and use my developer org, I can just do this pretty right.
[01:10:21] In fact, you use it if you have an enterprise or above, I know there's professional and essentials.
Right
But you're right. If you have and enterprise and above, you can actually do it in your production org.
Right.
But if you're on professional edition, you might be missing a lot of the functionality, like API that aren’t available in your org.
[01:10:41] You know, it's a licensing limitation.
Okay?
You could pay to add that on. So, it's got to be an enterprise or above. You don't even need to go and get a developer, but yes, you can do this from a developer or the cost to-go-to place is Trailhead.
Right?
And there you can actually create Trail, playgrounds that again last forever, and you can do this whole thing from there as well.
[01:11:03] So yes, actually developer org could be your dev org or Trailhead playground. Yeah.
I'm just thinking about the administrator doesn't want to go out and do anything in his production system to start with. You can do this all for free using Trailhead. They have a orgs, et cetera, VS code public.
[01:11:20] Great, perfect. All right. Well, it's a great presentation. It's a great capability, long overdue in Salesforce. Nice to see them developing it. And I appreciate your time and effort today. Bash.
You too. Thank you very much for your time as well. Thank you everybody for watching. Take care.