Implementing version control for infrastructure as code is just as simple as including our new infrastructure configuration files along with our application source code. When we create a new repository for our project, our infrastructure definitions are now included using the same versioning as the rest of our products files. It's really as easy as that. We can then roll back to previous server configurations in exactly the same way we would roll back any other changes to our application code.

Depending on the size of your project and development team, you can choose to implement either a single monolithic repository for the entire code base, or you might decide to break it into multiple repositories instead. A single repository is obviously easier to work with, especially for small projects and teams, and is what we'll be working with for our demos in this course.

By implementing multiple repositories for our code base though, we can apply different access permissions to our application source code separately from our IaC configuration files. This way, you could for example, give only your senior developers permission to make changes to your IaC configurations. The rest of the development team can still be given access to pull and use these configurations in their development environments without any risk of them accidentally pushing any bad IaC configuration changes to the repository.

Let's get started by pulling the repository for this course with a git clone command. You should already have git installed locally for this course. I will be working with Visual Studio Code for my demo. So for those following along there, all we have to do is open our new repository folder, click on source control, then click on initialize repository. We can now commit changes to our project files and track versions or rollback mistakes locally on our development machine. We can further reduce human error and speed up our development workflow by pushing our changes to Google Cloud source repositories and using a Google Cloud Build trigger to automate deployment of updated server images whenever there is a version change.

Let's take a quick look at how we can do this using the files already in our project. We'll go into greater detail about building and deploying IaC configurations using Google Cloud Build commands in the next lecture group. You should already have a project created on your Google Cloud account, and the gcloud SDK should already be installed, initialized, and connected to your new project.

Now let's make sure we enable all the APIs that we'll be needing. We can do this by navigating through the Google Cloud Console website and clicking on each of the services, or we could use these quick gcloud commands.

After that, we can very easily authenticate git with our Google account using this simple credential helper command. We are now ready to create a repository on Google and push our project code with these commands. Be sure to replace the project ID with your own project's ID here. You can also change the name of the repository here if you like.

Next, we need to create a Google artifact registry to match our source repository name. This is where Cloud Build will store our new container image for us. You may need to change the region to match your project here. From the Google Cloud Console website, we can now see our project code in our Google Cloud source repository and our empty artifact registry. While we're here, let's create a Google Cloud Build Trigger that will run the Cloud Build.YAML file from our project every time our cloud source repository is updated. This will automatically build a new container image and store it in the artifact registry whenever we push any code changes.

Now let's take a quick look at this Cloud Build.YAML file in our project. Make sure the region and repository names match from your earlier steps. We don't need to change the project ID here, because this is a variable in our configuration file that will be filled in for us at runtime.

Now save and push the changes to our Google Cloud source repository. We should then see our Cloud Build trigger running. And once it's completed, we can now find our WordPress Docker image ready for deployment in the artifact registry. We now have version control and build automation working for our project.