Git and other version-control software - Salesforce Tutorial

- [Instructor] So the next lecture, we're going to go over Git and version control. So we have talked a little bit about version control in previous lectures about having version control when it comes to some of the different pieces of business process mapping, specifically the universal process notation, that you'll want to have version control. So version control is just being able to go back and revert changes. But in more of a development scenario, version control relates back to Git and the system of Git, so where you have a central repository of the production environment. So let's say the production environment is just going to be a bunch of files. And that's going to be what's live on the website. What you can do is now you can take a copy of it, of this production environment. So get the copy, the file copies, and put it on your machine, your computer, if it's a desktop or a laptop. And then from there, you are able to develop in a copy of it that is not going to be the production copy of it. So once you have done the user story, and you have completed all of your testing, and you are ready to push it to production, you can then merge it back into production. Then you can take your development environment and, again, merge it back into the production version. So there's a lot of different terminologies when it comes to using Git, and so that's why I'm calling it merge instead of, like, put it back in, or let's... We'll go through a bunch of these different pieces of terminologies that you should know for the exam. Let's talk a little bit more about Git. So Git is going to be the main tool that most developers use when it comes to making sure that you have different version controls. So you're able to say, hey, this is the production environment. You're able to see who has put new pieces of functionality in, when they did it, and you can easily revert back. If that causes errors, it's really easy to collaborate. So let's say you had a team of five different developers. You each had your own copy of the production environment, and then maybe you had like a sixth and a seventh copy of it that was just for testing and bringing all of the new pieces of functionality together. So let's say we got production, and then we have seven different sandboxes that developers are going to be using. So each of the five developers are going to be working on a different user story within their sandbox. Now, as each one of them completes their user story, and they've QA tested it, then they are going to put it into the next sandbox for testing, for UAT testing, for doing all of the making sure like, hey, all these different user stories work together. Nothing's going to break when we put this into another copy of the production environment. You get all of your testing done there. And then you do a test release into possibly a full copy sandbox with all of those pieces. And then you're able to push that into production. And it's super easy to revert back. And it's also easy to collaborate with other developers. So now I'm also not going super deep into Git and into GitHub, which is something that you've probably already heard of. And it's not too common on the exam, but it is somewhat important to understand some of the terminology when it comes to getting context on maybe one or two questions on the exam but also when you're a business analyst talking with developers. If you want to go in deeper into Git and version control, there are some great resources on various platforms. So just do a quick Google search, and you should be able to find an explanation on different platforms. The first key term that we're going to go over is a repository. I know that we have talked about this in like a user training context where you're wanting to have a repository. So a repository is going to be a storage system, but when it comes to repository in Git and in version control, repository is a place that stores all the files and all the file versions in a project's history. So if we want to think of a Salesforce example here, we could think of all of the versions of a flow. So when you create a flow within Salesforce, you have version one, and then if you want to make changes to that after you've already put that live, you have to deactivate it, create another version of it, and then develop additional things on it, and so on and so forth. You could create up to 50 versions on a flow last, time I checked, and after that, you'd have to create a net-new flow. That is going to be repository, a space for something to be saved. So a commit is just going to be saving your work into the Git repository. Next is going to be stage. So this controls what gets committed and what doesn't get committed. So let's say you had six different files that you had been working on and creating. So you're going to stage those six, and then maybe you have two or three that you actually want to save, and you actually want to commit. So staging would allow you to select certain files to commit and certain files to not commit. So next is not going to be a key term, but a little bit of context before we get into the last few things. So a Git is going to be a file versioning system that stores on your local hard drive. So on your laptop, it's going to be on your desktop, whichever one you are working off of. Now, you've probably heard of GitHub. So instead of storing all of the files on your local hard drive, a GitHub is a service that hosts your repository, that stores your repository on a server offsite, which can be really great if you are working with a bunch of teams. And why a lot of developers work remotely is because they can do this with a server offsite. Next is going to be push, so you'll be moving your commit to a spot like GitHub. So let's say you have the files on your local hard drive, and then you're ready to put them into the offsite server repository. So that would be a push when you're putting it onto GitHub. Now, GitHub is probably one of the most popular service that stores all the repositories on a server offsite, but there are other places as well. Git is going to be the type of file-saving system, and then GitHub is going to be a place where you can save files. And then finally, we have pull. So it's going to be refreshing your local copy from a spot like GitHub. So it would be like refreshing a sandbox from Salesforce. And then a couple more, we have continuous integration. So this means that you are frequently merging your code changes into that shared repository. So it really depends on how your team works. If you are working on a Kanban system, where you are constantly pushing one user story at a time into production, or it could look like, at the end of a sprint, you are dedicating a couple of days or a day to merging all of your code changes into production. So continuous delivery is taking whatever you've built and then putting it into a test environment for testers to use. We have small user stories, and so you're completing those user stories frequently, and then you are going to be putting it into the test environment for testers. A lot of this just means that you're doing this a lot. You are continuously putting things into the shared repository. You are putting things often into a testing environment, and just things are being continuously done. It's more of a framework of getting development done rather than terminology for what things are called and how you do certain things. And the last two, I should say, are often referred to as CI/CD.