Introduction to Cisco DevOps

0:00Hey friends and welcome to the implementing DevOps solutions and practices using Cisco platforms course. So I thought the best way to kick off this particular course is before we actually dig in to any of the details what we should do is spend a few minutes to go over what the exam actually entails. So really as we can see here as per the actual official page here, this exam is going to test your knowledge on DevOps practices. So we'll be looking at things like automated config management, we'll be looking at cloud environments, we'll be looking at microservices and things like container ization, so on and so forth.

0:34And the first thing to note about this particular exam is this part right here, the associated certifications. So pretty much this exam here is a concentration exam that ultimately you take on your way to becoming a Cisco certified DevNet professional. So if you happen to be unaware of how Cisco actually structures that exams, they really have three different tiers you have the associate level, which is the entry level, then you have the professional level, and then you have the expert level.

1:04So very roughly the associates for beginners, the professional is for intermediate learners and the expert is for expert learners. So really this will be an intermediary course focused on these particular concepts. Now we can actually look very briefly at the exam topics in a little bit more detail, let's just look here. As you can see, we have six different sections, the first section is all about CI/CD pipelines. So in this particular scale, all we're going to do is to focus on our preparation to begin learning these particular concepts. So effectively what we'll do is build a little development environment whereby we will build a virtual machine, which we can use to essentially download and install the software that we need.

1:42And we'll also quickly talk about some basic concepts relating to get, which is super super important with respect to DevOps. And we'll also look at getting ourselves set up with a get top account and we 'll see how we can actually create repositories on get top. And then once we've done that in the very next scale, we will begin tackling all of the content that we see within this particular chapter care. So you see we have a focus on things like GitLab, things like Jenkins, CI/CD pipeline failures, the way we can roll out CI/CD pipelines, all that type of good stuff. Then the next section we will visit will be the packaging and delivery of applications.

2:15And this will really be looking at things like Docker and containerization. And then the next stage will begin down to automating infrastructure. Once again, notice the concepts of CI/CD pipeline still very prevalent, things like Git, things like GitHub will also be very relevant here. But we'll also be looking at particular tooling such as Ansible and Terraform. Then we'll briefly look toward the cloud environments. We'll get to see things such as AWS, which is Amazon Web Services, a super super popular cloud environment provider, as well as a technology known as Kubernetes, which is a great way as you come to learn to manage your containers.

2:51And then we have the subject of logging, monitoring and metrics. We'll get to look at things such as collaboration technologies such as Cisco WebEx and how we can interact with this programmatically using its API and Python code. Once again, we'll be looking at the technology known as Kubernetes and CI/CD pipelines. This is a huge concept within this examination. But of course, we're going to have a very heavy focus on, as you can see here, monitoring, logging. So that's all very utilizing things such as dashboards, so on and so forth. And then the final topic is a rather short one, as we can see here.

3:23And it's all focused around security. Now, once again, what do you see security as it relates to CI/CD pipelines, as well as how we can actually implement secure software development life cycles. So quite honestly, this is a very modern and relevant examination. So much of the tooling that you see here, so much of the concepts and practices are really at the forefront of the world of automation and configuration management. So basically what I'm saying is that it should be a blast to go through. Now, before we begin, like I say, we're going to have to get ourselves up and running with a nice development environment.

3:55So how about we talk about that in the very next video.

0:00Hey friends, so in this particular video, what I want to do is to talk to you how we can get an Ubuntu Virtual Machine up and running pretty much so that you have the same environment at home as I'm working with right here. Now I will say you do not have to use Ubuntu if you really don't want to, it just makes things a little bit cleaner, a little bit easier if you happen to be using the same operating system as me. So this is going to be the solution that I'm going to recommend. Now in order to get Ubuntu up and running, I'm going to use some type of virtualization software because I actually do not have a Windows machine or rather a Windows machine. I actually do not have a Linux machine running right now. I happen to be running a MacBook. Now quite simply, when I'm doing development, when I'm doing testing and demos, I don't want to work on my host machine pretty much. I don't want to risk breaking anything. And by the way, many of the most popular DevOps tools happen to be built for Linux. So it does make sense and makes things really quite easy.

0:54If I'm just working from that particular environment. So like I say, I'm going to be doing some type of virtualization. So what we need is some type of virtualization software. So you can use any solution you so wish, perhaps you want to use maybe say VMware, which is a very common one. If you happen to be using a MacBook, you would want to install VMware Fusion. If you happen to be on Linux natively or you happen to be on Windows, you would want to have VMware workstation. Or you can go and download another very well known and popular choice. This is Oracle 's VirtualBox. Either or it's going to be fine. Just take your preference. So choose one of your solutions, get your virtualization software up and running. And now let's discuss what we actually want to be installing. So check this out. Now I'm just going to search for Ubuntu desktop downloads. So the desktop means I'm going to have the full graphical environment. I'm going to be able to use things like my web browser, so on so forth. Whereas if you want a more minimal installation that uses less resources that just got a basic command line interface, you can just download the server version, but I wouldn't really recommend you do that because at times we're going to be using the functionality of the actual desktop itself. So it makes sense to actually have one natively on the box. Now one last point. What I happen to be using is a MacBook M1. Okay, this is an M1 chip.

2:07This is Apple's own silicon. Because of this, I have to download a very particular image. I'm going to have to make sure that my image is an ARM architecture. Whereas if you happen to be running Windows or an older MacBook that uses an Intel processor, you can just download the regular 64 bit installation. So in the case of the Windows downloads or the older MacBooks, you would click this link right here. And as you can see here, we have the Ubuntu desktop download and here it is here. And you just simply click this link and then you specify where you would want to save the image and just save and download it. Now in my case here, I want to get a very particular version. So what I'm going to also add on is the word ARM. Okay. Now if I just go for Ubuntu for ARM right here in this particular option, all that's given me is the Ubuntu server for ARM at the moment. Maybe when you watch this video, things will be a little bit different.

2:56But right now all I have is the server images without the actual desktop. So what I want to do here is if I go back, all I'm going to search is for this right now Ubuntu, J ami Jaylefish download ARM and I'll just collect this link right here. And if I just scroll on down, what we can see here is on the right, we actually have a 64 bit ARM architecture and it's a desktop image. This is the one that I want to collect. So let's click this here and all I will do is choose save. And now as we can see here, the download begins. So once you've done that, go and open up your virtualization software. In my case, I'm using VMware. So I'll just go and add a new machine.

3:29I'll choose the image that I want to be using. And if I scroll on down here as the Jami desktop ARM 64 image that I want to use, I'll choose continue. And then you can customize the settings for whatever you want. I'll just call this Ubuntu to and if you so wish, you can do things like add more memory. So on so forth. But quite honestly, the defaults should be okay. So once that's done, just start the machine and all I will do is try or install Ubuntu. So your environment might look a little bit different in my case here and present it with a desktop. And all I have to do in my case is just double click this link. Ultimately, this is the point we want to get to . So I'll just choose my language, which is English, choose continue. In my case, I'm in the UK so I 'll select that. But of course, choose whatever one fits your scenario best. And all I want to do is to make sure I've got a normal installation, okay, and then choose continue. And I want to erase disk and install Ubuntu and then choose continue. Now I'll just choose my location, which is going to be in the United Kingdom. So I will choose London as the time zone. And now I'll give it a name. So in my case, yeah, my name will be IPV zero. Just give the computer a name. If you so wish, call it server or system or my computer, whatever you want. It doesn't really matter. I'll just say server.

4:33And now just choose a password. So I'll choose a fairly simple password because it is just a lab environment after all. And I'll choose require my password to log in and then choose continue. So we just give it some time to copy over the files are necessary. So the installation is now complete. I will just choose to restart. So if you happen to be experiencing the same thing that I am right now, you might think that something is wrong. We see a failure, but don't worry about it. In this case here, all you have to do is press enter. And then if you give it a moment to reload, it begins to boot up once again. And now as you can see here, I actually have my log in. So if I hit enter and then type in the password that you created when the account was made and then hit enter, then just choose skip next, next, next, and done. And all I'll do is go into my preferences, go to unnamed. And all I'm going to do is just change the font size to be a little bit bigger.

5:20So going here, move this up a little bit. Now maybe your installation was a little bit different depending on the platform that you were using. But broadly, those are the configurations that that you would want to set in order to get yourself up and running.

0:00So here's the thing now we have an Ubuntu machine up and running. What I now want to do is I want to install what is known as an IDE. This is an integrated development environment and basically this is just an application that's going to help you write your code, manage your configurations for DevOps, that type of thing. So the one that I'm going to recommend you install is VS Code. This is a super popular solution. As you can see, you can download it for Mac, Linux or Windows. So here's the thing. I actually have my MacBook right here and I also have my Ubuntu virtual machine .

0:31Now as it transpires, I'm going to actually download the software directly onto my host machine, which is my MacBook. That means that VS Code will be on this machine and I'm actually going to use an SSH connection to SSH from the application directly into the virtual machine so we can actually use the app on the host machine and it will actually make changes on the virtual machine. But if you want to log in to the virtual machine itself and just download VS Code directly on the Linux box, you can do so also. This is just my preferred way of doing things. I like to work within my actual host machine. So this is the way I'm going to recommend you handle this. So depending on your environment, select Windows or if you happen to be on Linux natively, select if you're on Debian based systems such as Ubuntu or a Red Hat based systems such as Fedora, Red Hat, Rocky Linux, so on so forth. But in my case here, I have Mac OS.

1:20So I have the Apple Silicon so I'd want to download this. So all you have to do is download the software, open it when it's complete and just follow the installation steps. So once you run the application, you should see something quite like this. Now mine will look a little bit different because I have been using this application for a long time and you're going to see old configurations here. Do not worry about it. What I want you to do is on the left hand side, go and click remote Explorer. Now what I'm going to do is I'm going to go over to my Ubuntu machine and I want to get two pieces of information. I want to get the IP address of this machine, which in my case here, if I type the IP adder command, I can see this is the address to connect to this device. So all I will do is just copy this right now. And now the next thing I want to do is to type sudo apt install open SSH hyphen server. This is going to effectively allow SSH connections into this particular machine.

2:12So I would just say why and to enter again. And once you've done that, if you take the command systemctl status on SSH, you should see that SSH is now active and running. So if you press Q2 quit, what I want to do is to now go back to my VS code. So here I am. And what I want to do is I want to look at my SSH targets and click the plus sign I'm going to add in new targets. And all I want to do is I want to type in how I would log in via SSH to that particular device now recall. In my case here, I have the address of 192168.168.168.138. This is the address I want to connect to.

2:47And this is my login username IPV0. In your case, choose your own username. So all I will say is SSH give my username, which is IPV0. And then the add symbol and then type in IP address. So I'll do add 160.138 and I hit enter. So I will just hit enter. And now I will choose connect down the bottom right here. Now for whatever reason it did not connect to that was a little bit of a bug. So all I will do is right click and I'll just choose connect to host in a new window. So now it's giving me the fingerprint. Do I want to continue? I will say continue. And now I just type in the password for my username. Okay. So if I hit enter give it a moment, you can see it in the right hand side we're downloading the VS code server. And now if I go to view and let me just zoom in a little bit so you can see a bit better. And then I get down to terminal. What you can see is we've actually opened up a terminal on the Ubuntu machine right here. So if I do an LS we can see my documents, my downloads so on so forth. If I do an IP adder notice the IP address is showing IP address of the Ubuntu machine basically it's like I'm working within that directly utilizing VS code. And the cool thing is if I just go up to VS code, maybe say new file inside the fear I have my VS code text editor and I can just say this is just a test. And if I just press command

4:03S or control S to save it, I can now specify where I want to save it in. I can just save it and let's maybe say my home directory and just call it my file dot txt, hit return. It's now saved. If I go back to my terminal right here, doing LS, we can see here indeed we have my file dot txt and I can cat the file to open it up and we can see the content. And once again, if I actually go back to the virtual machine, just directly to it to do an LS, we can see the file has actually been created on the machine itself. And we can see once again, the content is just there. So this is going to be the environment I'm going to recommend it's going to give you an option for utilizing things like plugins, which is going to help you manage, say, for example, configurations with respect to tools like terraform and Ansible, so on, so forth. So now that we have our environments up and running, let's now talk about a very important skill that we need for DevOps operations.

0:00Okay, let's talk DevOps. To with respect to DevOps, we're going to be learning about things such as CI/ CD pipelines. We'll learn about configuration management tools. But there's one particular technology that you're going to be utilizing over and over again when you invoke these types of technologies or approaches. Now what exactly is this? Well, we're talking about something known as Git. So because Git is so often used because it is so integral to CI/CD pipelines to DevOps, so all I want to do right now is to take a little bit of time to ensure that we 're all up to speed with the basics of Git.

0:34We don't have to worry about too many advanced concepts, certainly not. But having some familiarity with the absolute basics, if you want to work in the world of DevOps, having this under your belt really is non-negotiable. So with that said, let's get hands on. Let's do some operations with Git. So very first thing that we're going to be doing is actually installing Git on our system. So I will just say sudo apt install. Git and to enter, give a moment, hit Y and enter again. Now Git is going to install. And boom, we now have the software.

1:05Now what we're going to have to do at the beginning is to actually specify a name as well as an email that we can associate with our Git operations. Pretty much Git is going to allow us to implement what is known as version control. So if we have a particular file, a particular piece of code, that type of thing , if we want to make a modification to this, then we want that modification to ultimately be tracked. Because you know what happens if you write bad code, you may have to reverse gears and go back to the original working version before you made the breaking change.

1:38Now basically when we make our changes to our files that are going to be tracked, they're going to be associated with a particular user and a particular email address who made the change on the team. This is information that we want to configure right now. Now there are two ways in which we can do this. We can specify global configurations and it would be helpful if I could write that correctly. Let's try that again. Global conflicts. Now this is going to mean that the name and email is going to be the same configuration for all of our repositories and our repositories.

2:08You can just imagine them as like a little folder or a parent folder that contains all of the information about your project, all of the sub folders, all of the files , that type of thing. And the repository is the thing that is going to be version controlled and tracked. Now as you may suspect, you can have different projects, you can have different repos. And if maybe you wanted to have a different username for every single repository and a different email for a different repository, that type of thing, you could configure the configuration to be on a more individual basis.

2:39But in my case here, everything is on my machine right now. I want to have it associated with a particular user name of IPV0, which is my username, and another particular email, which is my email address. So let me go and show you how we can get this up and running. Let me just take clear to clear the stream and I'll just say get config. And I'm going to say dash dash global because this is a global configuration. And I will say user dot name and then in my quotation marks, I'm going to give my username that I want to associate. So me is IPV0, let's just enter.

3:09And now we have the configuration. If I just happen to say get config dash dash list and hit enter, look at this right here. This is my get configuration so far. This has been successfully added. Now let's add in the emails. I'll say get config. Again, it's going to be a global configuration. This time I will say user dot email. And again, in my quotation marks, I'll just type in my email address. Okay, so I'll just put this in. And again, hit enter, Rwup list the configuration. Now we can see we have both email and username configured.

3:39Perfect. What I now want to do is I want to create a little project. So to speak, it's a kind of a pseudo project. So I want to do a real project, just effectively a little folder so I can show you some basic version control information or version control operations when working with files. So what I will do here is I will just create a little directory using the mkdir command and I'll just say my test project. Okay. The name itself doesn't actually matter. Call anything used to wish. Now I'm going to cd enter that directory, which means I will move into the directory.

4:10And if I do an LS to list the contents of that directory, nothing is appearing on the screen because nothing is actually inside this directory. Now if you actually use a very particular switch in Linux and say LS dash LA, it will actually show you anything hidden within the directory. Now right now again, nothing of notes. So what I want to do is I actually want to initialize this folder as a get repository so to speak. So what I will do here is I will say get init. And if I just hit enter, what it says here is we have initialize an empty get repository.

4:43And now it says empty because we don't actually have any files. Again, we don't list a list. We see nothing but now if we actually list the hidden contents with a dash LA once again, look what we have here. We actually have this dot get folder. Perfect. So check this out. What I want to do is I want to go and create some files and I'll do some version controlling of these files. Okay. So what I will do here is I'll create a file. I should call this my first file dot txt. Okay. Not all I will do is go into VS code. I'll open up the file. Go to my test project and then click the file right here.

5:16And all I will do is say this is my very first file, exclamation mark. And I'll just press command S to save this particular file. Or if you still wish by the way, what you can do is go up to the file here and then get down to save. That is also going to work. Now what I will do is I'll create a new file. I'll just save my second file dot txt, go up here, open it up and go into the second one and just say this is my second file. And again, we can just go and save this. Perfect. If I do an LS, be list the contents of my directory, we can see we have my first file and my second file.

5:49Now right now, these particular files will still do exist in a get repository. They're not actually being tracked by a git. And the way I can test this is a very important command you want to remember. If I say get status, what we can actually see here is we have two untracked files within our get repository, meaning that if I happen to make a change to a particular file and for whatever reason, I want to go back to an older version, that is not going to be possible with git because the file has not been tracked at all. So let's actually add these to our get repository so that they are tracked.

6:19Now the command we want to do here is to say get add and then we can add in the name of the file. I can say get add file one dot txt or rather not fail one, my first file, apologies there. And I can just hit enter and that's going to add the first file. If I now say get status and hit enter, look at this right here. We have changes to be committed. This is for the fail we're tracking but still right now my second file is untr acked. So what are we going to do? We can again say get add my second file. Now this will work absolutely but if you happen to have many, many files you don't want to have to continue to repeat yourself, what you can see is get add and then do an asterisk.

6:57And that will just tell get to track everything within this directory. So if I hit enter and now you say get status or once again, now we can see we have our two files being tracked and ready to commit. So when we say commit, we are essentially committing them to the get records. So every major change you make to a file you want to effectively record it and get and the way we do this is via the commit. So now let's commit these. We'll say get commit. We'll say dash aim for specifying a message along with the commit. Now just to just testing my first commit will be my message.

7:30And then I specify the files that I want to commit. Now similar to when we added the files or rather to use the correct terminology when we staged the changes, this is effectively what we want to do before we make our commits. We want to stage the changes which is kind of like preparing the file to be committed. What I can do is just specify the name of the file I want to commit. I can say my first file and then I could maybe say my second file or if I so wish I can once again just use my asterisk to say hey commit everything all files within the directories if I hit enter. Now we can see here we have two files changed, two files have been inserted and now these files as they are right now have been committed to the get record.

8:09Here's the content of the first file and here's the content of the second file. Now if I just go back into my second file and I say this is some more configs. Let's imagine it's a configuration file for example and say the changes. If I say get diff on my second file what I'm asking get to do is to check if there's any differences between the committed state of the file and its current state basically has anyone made any modifications. So let's hit enter and we can see here the original file initially just said this is my second file and that has been removed so to speak it's not really been removed but get sees it as a removal because we have a new entry and the line now says instead this is my second file this is some more config.

8:50So we can see here straight away this here is the new content of the file itself. Now let's just say for whatever reason we liked this configuration change. We had done sufficient testing we like it we want to save it. So what I want to do is I want to commit it but before I commit it what am I going to have to do I'm going to have to stage the changes. So I'll say get add to stage the change and again I can use my asterisk to stage all potential changes or you can just be explicit and say I want to stage the changes for my second file.txt particularly.

9:22So let's stage the changes and now what I can do is I can say get commit dash end to specify my message and let's just say the message is updated configurations and then we specify the name of the file my second file dot txt and bam we now have a new commit for that particular file and you'll notice now if I take the command get log we actually see a log of all of these changes here is the first commit that I made we can actually see the time and the dates and then we can see the second commits whereby we have our updated configurations which is the message we supplied and again time dates and the author as the username we configured and the contact as the email we also configured.

0:00Now that we know how to stage and commit our changes, what I now want to do is to briefly talk to you about the concept of branches. Now branches are one of the most important things to understand about Git. So let's find out why. Now conceptualize our commit history as kind of like a timeline of events. Every time you happen to commit the changes you make, you effectively add in a type of snapshot of the version of that file into the timeline history. So imagine you make a commit right here, okay?

0:30And then some time passes and you make some changes to a file, you'll like the changes and you want to take that snapshot of that file once again so you have another commit. And again, maybe later you update some configurations once again, you like to commit these changes so you commit it once more. So this here would be the latest version of the file. Now right now this is all in one timeline. You have the current state of the file, you have a snapshot of an older state of the file and a snapshot of an even older state of the file. Now this timeline here is referred to as a branch.

1:01And in fact the timeline that I'm operating on right now is known as the master branch. Now you might also hear the term main branch, which is a more modern name for effectively the same thing. You'll tend to see both in the real world. Now conceptualize this, imagine we've got an entirely new file, okay? So you make a change to this particular file here as a commit and then through some time you add another change. Now let's say these are representing configurations of maybe say your infrastructure, okay? Maybe it's a terraform configuration file, that type of thing. Now suppose the changes that you are proposing are in essence experimental.

1:36Basically you're not really sure if these configs are going to work or blow up the network. So you don't really want to commit these changes into the history of your main or master branch. So if you don't want them in the actual branch itself, what we would like to do is to split out and create a second timeline which would be our second branch. And this is exactly what I'm talking about right here. So imagine as opposed to just going and you know, going and making a third commit into the master main timeline, instead we will take the information from the previous commits and we'll actually branch off and create a secondary timeline right here.

2:15So now here we're creating a new timeline and now we have our commit with our experimental changes. Now this new branch or new timeline can have any name you so much, you could call it the test branch or maybe the dev branch for development, that type of thing. These types of names are very, very common. And let's just say you just want to continually test out these new features and you want to keep making snapshots that you can effectively reverse back to. So whilst in this test branch, you make some more changes to the configuration, you're not quite so sure yet. So once again, you create a new commit within the test branch.

2:48Right here is our new timeline. Now eventually what might happen is you gain a lot of confidence in these changes in the test branch and you say, hey, I like these changes so much that I actually want them to be in the timeline of my main branch. And what's going to happen is you can effectively take these changes and you can in essence merge them into the main branch once again and then you continue on your timeline of the main branch once more until of course you again want to branch out, switch to a test branch or development branch and begin making more experimental changes.

3:20This really is the concept that I want to highlight here and it's very, very important in the world of DevOps and in particular with things like CI/CD pipelines. So let's actually look at it and practice them. Now you'll notice or you may have noticed what I say when I happen to download Git, or rather not do you look at it, when I happen to initialize my Git repository there actually was a little bit of text that came up on the screen and it told me the name of the branch that I happened to create. Now we can actually see this branch if I just take the command Git branch and to enter.

3:51Look at this right here, we see all of the branches that we have. Now I only have one branch which is the master branch and we know we are on that particular branch or in that particular timeline because it has an asterisk next to it. As it stands right now, whilst I'm operating on the master branch, well be committed into that timeline. Okay, so let's go into let's say my second file once again. Now suppose I want to add in some new configurations. Now of course these are not actual configurations I'm just simulating them and suppose that the configurations that I was going to make are a little bit dodgy.

4:22I'm not quite so sure about them okay. So I think here I'm going to make these changes but I don't want to do this on my master branch. So here's what I do. I first go and create a new branch entirely. So what I can do here is I can say get check out and try to remember this command dash B to specify the name of the branch that I want to create and now I just list the name that I want to choose. So I'll just maybe say develop branch okay. So I hit enter and look at what we actually see here. It says switched to a new branch develop. So we didn't just create the branch, we also created it and switched to it.

4:54So now if I take the command get branch, we see the two branches that we have created and now next to the asterisk we see the develop branch indicating that we're on this particular timeline now . So now that I'm on the develop branch, if I just happen to say get log, notice we actually see the previous history. But anything we do from this point on is not going to affect the master branch unless we perform what is known as a merge operation. So now that I'm on the test branch or the develop branch rather, what I will now do is put in my rather experimental configuration.

5:25So I'll just say this is some dodgy config that I'm unsure about. Cool. So let's save this. If I say get diff on my second file, we can see here we have some changes made and let's say I want to commit these changes. So I stage them. So I'll say get add asterisk and hit enter. And I now say get commit dash M for the message. And I'll just say testing out some new configs. Okay. And now specify the name of the file that I want to commit. So I enter here we have our new commit. Now if I just say get log at this point, look at what we actually see here.

5:55We see the previous history and look at the actual brackets here. We see this is the master branch. But now this particular commit here is inside of the develop branch. See that right there. Now if I do an LS, we can see we still have all of our files. Now watch this in particular. Let me just look at this right here. Okay. Let me clear the screen. Now again, the branch that I'm on right now is develop branch. And this is the version of the file within that branch. Now if I just switch back to my master branch, and I can do so by saying get check out. And then we don't use a dash B.

6:26We're not creating a new branch. We just specify the name of the branch that we want to flip to. If I say master, watch what happens to the file above as I hit enter. Look at that. See that now we've switched to master branch. And the content within this particular file is actually unchanged. We don't have this new weird potentially dangerous development feature inside the file. We just have the well tested and secure version of that file so to speak. So again, LS, we see your files. If I say get log, notice in the get logs, if I scroll on up, look at the last commit within this particular timeline.

6:58It's just the updated configurations. Whereas again, if I go down, if I say get check out develop and hit enter, look at this straight away. Suddenly the configurations come back. So let's for whatever reason say we test these configurations. We no longer think them to be dodged. We actually have strong confidence that these happen to be pretty good configurations. And we want them to be present inside of our main timeline. The main versions of our configuration files that ultimately will be used in production. Here's what I want to do. I want to perform this merge operation. Now the first thing I want to do is I want to make sure that I'm on the branch that I want to be merging into.

7:34So I want the changes to be merged into the master branch. So right now if I say get branch, we can see I'm on develop. So what I want to do is to first switch back to master by saying get check out master. Now if I say get branch, the asterisk tells us we're on get master. So now what I will do is from the master branch, I will just say get merge. And then the name of the branch that I want to merge in. So I want to merge in the changes from the develop branch. So I'll say get merge develop and to enter. Suddenly the new configurations are present but they're actually present within the main branch now or the master branch.

8:10So if I say get branch now, I can see I'm on the master branch. And look at this right here. The once experimental configurations are now present in the main timeline. And now again, if I happen to say get log, as we can see here, now we have this new commit. And we can see here this was from the develop branch now in master branch. It really is a very important concept to understand when working with configuration fails called that type of thing.

0:00So here is the thing. It is very very unlikely that you're going to be dealing in a DevOps environment, any silo, meaning that you're not going to be working all by yourself, much more likely instead you're going to be involved in some type of collaboration. So in this particular video, what I want to do is I want to highlight the concept of having a remote repository that is ultimately going to act as a type of centralized source and an intermediary point between a whole bunch of different members of a team. Because right now it's all very well and good. Well, I on my machine right here make all of my changes that are all version controlled. I've got my own branches. But let's say I happen to be a member of a team whereby we're all contributing to the same type of code, the same code base or maybe the same configurations. How on earth am I going to be able to make my nice version control changes and have them be shareable and accessible with other members of the team? Not everyone after all is going to have access to my laptop nor should they. We need a way to effectively transfer our changes and make them available to other people. So imagine this here I am right here on my machine. Okay, let's just say this is John's laptop. And let's just say I've got an application called application dot py. It's a Python file. Okay

1:15. Now I may change this to my file on this particular machine. But really this is just one file in a larger project. So let's say we've got another developer called Samona. Now Samona would like to have access to the changes that I've made in my particular file so that she has the updated version. Now how are we going to effectively pass these changes about because maybe Samona has got another good idea to add to the code base and she also wants to effectively make that change available to me also. So step in the world of remote repositories.

1:47Now the most well known remote repository perhaps you've heard of it is one called GitHub. Never ever confuse us with get itself. Okay, just because the name has get is not the same thing. But it does integrate well with get itself. So imagine this as the architecture . Let's imagine we've got the big wide internet out there. Okay. And this is where GitHub actually lives. Now I hear with my laptop make some changes onto let's babysate my production branch. So over here I make some changes to my application. Now what I want to do is I want to effectively push those changes to a remote repository so that they happen to be available on the internet. Okay, so I'm pushing them towards GitHub. Now that they're available on GitHub, what Samona can do here on her computer she can send a request to GitHub to in essence pull in the changes so she gets a copy of my code as it's been updated on her local machine.

2:43And then when Samona wants to make a change to the code base she can commit those changes and then push these new changes to GitHub. And as we're building my building my building what do I want to do? Well, I want to get a copy of the latest change. So once again I pull in some money changes and now I can begin working on these version control files on my system too. And of course you can extrapolate this to include many more developers, many more contributors. But in this case here just with two people you can already see the advantage of having this centralized intermediary point whereby we can effectively post and retrieve our data. So what I want you to do is to go to GitHub and create your very own GitHub account. So let's go and do that then. So if you just search for GitHub on Google and click the top link right here what I'm going to do is I'm going to choose either sign in or sign up if you don't have an account you want to sign up of course just go through some of the details provide some information like an email address your username that's type of thing have a password. But if you have already created an account which I have then you want to choose to sign in. Okay, so now I have logged into my account what I'm going to do is I'm going to select new for a new repository let's click this here.

3:54Now all I'm going to do is give the repository a name. Let's just call it my app. Okay, and we just say repository for my application. So imagine this is where all the code for my application is going to live. Now I can specify whether or not the repository is going to be public or it's going to be private. Now if you don't care about people seeing your code if you want it to be open source and fully shareable then you can make the code public whereas some companies some teams they would prefer their code base to actually be private. In my case here I will just choose a public repository. Now all I will do is I will choose and add a read me file to initialize the repository and now all I will do is choose create repository and bam that is us we've now created a repo for my repository we just don't really have any real information and it no actual code exists quite just yet. So this is our code base out in the insonnet. Now what I want to do is I want to get a copy of this code or rather a copy of this repository on my own local machine. So what I'm going to do here is if I go to code and click this now I can just copy this particular URL which is the URL to the repository and all I will do is I'll go back to my terminal. Now right now as you can see I'm inside of my test project this is a completely separate

5:10repository this is not the one we want to be working on. So all I will do is I will say cd to take me back to my home directory and what I want to do is I want to clone this repository so I'll just say get clone and then paste in the URL. If I hit enter we're going to download that repository so that it's now accessible to me on my local machine. Now because this is a public repository I didn't have to type in any type of credentials. If it was private I would have to authenticate that I do actually have access to read the information within this repo but because like I say it's public let's just go and cd into my app.

5:44If I hit enter and I now say get branch. Look at this right here but actually on the main branch of the my app repository now again if you don't recall the previous version or rather the previous repo actually referred to in master branch now in the case of get to write here they're calling the master branch the main branch but basically it's the same type of thing. So what this now means is that I'm on the main branch and if I so wish I can create files or just to touch my underscore code dot py let's go into this particular file.

6:17So it's going to the my app directory and then into my code dot py or to say this is just some Python code again pretending that I'm writing some code right here and I'll save it and now what I want to do is I want to essentially stage these changes so I say get add aesthetics to add then everything if I say get status now we can see the files I'm tracking now if I just go to my get a repository once more if I refresh the page here notice nothing is actually happening the get repository still doesn't have that newly created file we're going to have to essentially commit these changes and then we want to push them to the remote repository so now with stage the changes we 're going to go with a commit so I say get commit dash m I'll just say my first push to get to up okay and then I'll target everything I have which happens to be just one file now here comes the part whereby we want to push the changes now in order to do this we want to actually authenticate with my account so what I'm going to do is I'm going to go to my account here I'll click and go down to settings down the left hand side I'm going to check developer settings and now I'm going to select for personal access tokens and then choose tokens classic okay and then I'll go up to generate new token and again same again generate new token classic and now I'll give the token a name here's a note I'll just

7:35say my first test token now I can say how long should this token actually live for so you can specify seven days, six to days, a customer amount or have no expiration I will just say custom and I'll make this token expire tomorrow so pretty much when you see this video this particular token is not going to exist anymore now I specify this scope for this particular token ie which permissions should this token actually grant me should I be able to write to my repository or only read from it should I be able to write to particular branches so on so forth should I be able to delete repositories you can specify all of this and these check boxes here so right now I'll be super liberal just check pretty much everything which by the way is not best practice I'm just giving you an idea of what you can do in fact I'm not going to check absolutely everything I'll just check a few things okay so let's just generate the token now here it is right here and I'm going to copy this okay so it's now copied now here's the thing when I go to effectively push to my repository I don't want to have to continually paste in this token over and over and over again what I want to happen is I want this particular token to be remembered by git now right now if I say git config - - list we can see our configurations I have my username I have my email we see the remote origin URL why I also want to do is I want to

8:51specify my git configurations actually remember the credentials I pass in so I'll say git config - global and then I'm going to say credential dot helper and then space and right store okay so if I hit enter here what this means is if I just list my config once again we can see here I'm going to be saving my credentials now here comes the push what I will do is I'll say git push - you origin and then I specify the branch that I want to target now the branch that I'm on is the main branch remember not master so if I hit enter I'm going to have to type in my email address here so I'll just type in my login details hit enter and now it says it wants my password now my password here is actually just going to be me pasting in the token I just copied over here I'll just paste in my token you 're not going to see on the screen just hit enter and now we can see here we have written our data on the target repository so if I now go back check this out right here out on the internet right now you can see I have my file my code dot py and if I just click it here we can see the content right here now again it's not valid Python code nevertheless but you can imagine if it was now it is publicly accessible so if anyone wants to collaborate with me but what they can do is they can

10:07effectively copy and pull down the latest version of this repository and then they'll have access to it similarly just as we saw before what I can also do is I can say git check out -b and I can create maybe a test branch okay so now if I say git branch and to enter here we have our test branch and once again we see our files now if I go into my file or say this is some new code features save you what do I want to do I want to stage the changes so I'll say git add asterisk also git commit -m trying out some new codes again I'll just do asterisk to add everything and now I can say git push -u origin and now the origin is going to be the test branch okay so if I hit enter it remembers my credentials and now we've actually set up a new test branch so if I go back to get some once more check this out right here we actually have a new branch okay so if I happen to click the my code and the main branch this is going to be unchanged which we can see right here the feature is not there but if I go back and I just say I want to see the test branch and click this now I'm on the test branch if I click the code now now we can see we have the new experimental features and these really are just some of the core fundamentals that we have to understand as we begin to look at things like cicd

0:00So friends, let's walk through the validation challenge. The very first thing I would like you to do is to create a new directory called validation there and initialize it as a get repository. Next, I want you to create global credentials specifying your username and email address and then list your configurations. Once you've done that, I want you to create a file called validation.txt and write your name as the actual content within it. Then stage and commit the validation.txt file and add the message validation commits.

0:31Once you've done that, I want you to inspect the get log before creating a new branch called test and open the validation.txt file from within the test branch and add a new line saying validation check. Once you've done that, I want you to stage and commit to these changes. Then I would like you to switch branches back to your main or master branch and check that the file and this branch only shows your name so pretty much you don't want to see that validation check line in the main or master branch quite just yet. Once you've confirmed that, then go in and attempt to merge the changes from the test branch into the main or master branch and now ensure that the file has the validation check line in both branches.

1:12So boot up your terminal give it a thank and I will see you in the very next video where we discuss the solution.

0:00So friends, let's walk through the validation challenge. So the first thing I'm going to do is to create a new directory called validation.dear and initialize it as a get repository. So I'll just say mkdear validation-dear. And now I'll go and initialize it as a get repository by changing into that directory and just saying get a net and to enter. And now we can see the empty repository has been created. Next, I'm going to create my global credentials, specify my username and email address and then list my configurations. So I will say get config-global user.name.

0:33And my username is going to be ipv0. I enter and I'm also going to create my email. So I'll say user.email is ipv0@gmail.com. And let me just zoom out a little bit. Keep it all on one line. There we go. Now I'm going to specify what my configurations are. So I'll say get config-list. And now we can see what I have configured. Next, I'm going to have to create a file called validation.txt and write my name as the actual content. So I'll just say touch validation.txt. So I'll open the file up and just add my name as the content, john McGovern, and just save this.

1:08So now as we can see here, I have this file with the contents. And now what I want to do is I want to stage and commit this file and add the message validation commit. So the first thing I will do is say get add and then the name of the file. And then I'll say get commits-m and then specify the message. So to say validation commits. And the file I want to target is validation.txt. And now we have committed the next thing I'm going to have to do to inspect my git log, which I can do via the command git log. Here we go right here. And now I'm going to have to create a new branch called test.

1:39OK, so what I will say is get checkout -b for the branch and then give the name of the branch test. Now we can see we'll switch to the new branch and we can check that out by saying get branch. Here we have our asterisk to ensure we are on the test branch. And from this point here, I want to open the file and add a new line called validation check. So I'll go into the file and I'll just add the line validation check and save this. Now again, I'm going to have to stage these changes. So I'll say get add validation.txt. And we're going to have to commit them once again. So I'll just say another commit as the message.

2:10And to enter, we can now see I have a second commit. And now what I want to do is I want to switch branches back to the main or master branch and check that the file in this branch only shows my name. So right now, as we can see, I'm on the test branch. And if I just say get checkout and go to the master branch, I've now switched to the master. If I look at the file once again, the file here now only says my name. Now what I want to do is I want to merge the changes from the test branch into the main branch or the master branch if you so well. So all I'm going to do is ensure I'm on the branch that I want to merge into, which is the master branch.

2:43And then I will say get merge and then specify the branch that I'm merging from. So I want to merge from the test branch. So I will say get merge test and to enter. So now as we can see, I'm still on the master branch. And if we now look at the file, notice the file also now has the validation check. And again, if I switch back over to the test branch and I look at the file again, we still have the validation check line right there. So that is us for our validation challenge on utilizing get. I hope this has been informative for you. I really to thank you for viewing.