Enterprise DevOps & Cloud Infrastructure

Creating a GitHub Automation Repo

Erik Reinert

Erik Reinert

Enterprise DevOps & Cloud Infrastructure

Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Creating a GitHub Automation Repo" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik discusses the separation of automation workspaces for Terraform Cloud and GitHub in a GitOps workflow. A new GitHub repository is created to automate the creation of additional code repositories. Questions about using branches instead of repositories are also discussed in this lesson.


Transcript from the "Creating a GitHub Automation Repo" Lesson

>> So okay, let's talk about what we've done, right? And let's kind of just recap really quickly, because again, there's a lot going on here, right? So I'm gonna pull up that chart one more time, because I do feel like it helps to see a visual aid, right?

We're using Terraform cloud. This is where all of our state exists. This is where all of our source of truth in the sense of what we've changed exists, right? And in Terraform cloud, although unfortunately we won't be making teams this time, right, it then has the concept of teams.

So then underneath teams, we would have our main automation workspaces, right? Each one of these workspace has a different problem that it's trying to solve with state that it's going to manage, right? So in this case, the first brick we were essentially building was the TFE workspace, right?

This is a part of the chicken before the egg scenario, when we wanna make it so that we can push automation to a repository and just be done, but the workspace that tracks that repository is not set up yet, right? So we then create our repo first so that, again, once we have our workspace created and they're in the same state, meaning that the code that created the workspace is now in the same state if it tried to apply over and over, we then connect them.

So we have no changes here and no changes here, and then when we connect those two, they start synchronizing, right? And so now that we have this synchronization, we can just go to our TFE repository going forward, to push changes, which is what we saw, and why we then saw the plans automatically start running in Terraform cloud, right?

So again, it's that chicken before the egg where we have to say, this is a scenario where it doesn't exist yet, but once it does, it can be completely automated. We need to do the same thing for GitHub, right? GitHub is kind of in the same boat where we need to create the repo that tracks and creates all of our repositories, and we need to create a workspace for it.

So we have actually finished the automation setup for Terraform cloud. Going forward, if you need another workspace, you now know how to do it. If you need another project, you now know how to do it, right? That's it. That's it, [LAUGH] that's all that repository really does. But if you think about it at scale, right, when you've got 50 projects and a hundred workspaces, this becomes really nice, right?

And this is that life cycle. So again, if you don't know, if you go to the next repo we're gonna be creating, which is terraform-github. So that's gonna be fem-eci-terraform-github. Let me copy this link for you and give it to you guys really quickly. This is the next repo we're gonna be creating.

And this is where you can copy and paste the code. And the branch that this exists in is gonna be 04-setup-github-automation. So this is technically the branch that we're gonna be working in. Now remember, this branch is also the end result. [LAUGH] So use it as an example for now.

And if I tell you to copy something, just be aware of what I have up here versus what you're copying, okay? So what we wanna do is, we want to, again, create a repository for GitHub the same way that we created a repository for Terraform. But can we do that in automation yet?

Can I have Terraform create a repo for me yet? No, why not?
>> You need the provider.
>> Well, yeah, I need the provider, yeah, exactly, and I need GitHub. So what we're gonna do is, I could say, you know what, let's just put it in TFV call of the day, I could.

But then that means when I go to update Terraform resources, I'm also gonna be updating GitHub resources. That also means that that pipeline needs two secrets now instead of one. That also means that that pipeline has more of a chance to fail if one token expires and the other one is still there.

This is why we separate life cycles, right? Save ourselves problems in the future. So what we're gonna do is, we're gonna go to GitHub. I'm gonna go to my personal profile repositories, right, and I'm gonna click New, right? So I'm gonna create a new repo under my personal account.

And in this one, we're gonna say, fem-eci-terraform, right, cuz the TerraForm repository GitHub, right? Same thing as before, Private, Add Readme, and another TerraForm, Git ignore, right? So then I'm gonna click Create repository. And now, I should have a fem-eci-terraform-github repository. I'll give you guys a few seconds to catch up on that.

>> Is it possible to do what you're doing with separate branches instead of separate repositories?
>> [LAUGH] I love developers [LAUGH]. Yeah, I mean you can, but then you have to manage branches. So what happens if your branch gets deleted? What you can do then? I understand why you don't want to create things and have to deal with more things, I do, trust me.

[LAUGH] There's a valid reason as to why we're separating these things, and it's over years of me failing and going through these pain points and realizing time and time. It's like one of those scenarios where you know something's gonna fail. You know eventually, if you think about it hard enough, there's a pinpoint somewhere that could break.

And if you don't consider that and separate it properly, you're just gonna have problems. So yes, you could put it in a branch, absolutely, you totally could. But again, then you have to think about branch protection, make sure nobody deletes that branch, right? You have to make sure that that branch also has permissions around it for approvals and things like that.

The repo is a production repo, if you really think about it, right? And so your branches are just really branches to that production main branch, right? But if you have additional branches that are also production branches equivalently, then it doesn't really matter necessarily where they are, but you have to be aware of that.

I personally decide and choose to separate them and make it easy just because I have so many components that I'm dealing with. It's just easier to make sure I'm not gonna trip over myself. So yeah, you definitely can, but I really do think that you're gonna, I would be terrified of a branch getting deleted or something.

Normally the main branch, it's something that's deleted. But you can, you absolutely can, yeah, not recommended though.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now