Overview
This is the third wave. The initial article made references to different waves but as I progress, the waves show what the priorities are for getting the environment back up.
For example, I spent a lot of time getting the Inventory back up since that’s where all my inventory hosts files are located for Ansible. This let me add appropriate tags and rebuild the hosts files so I wasn’t doing any steps manually.
Gitlab
Next up is to get Gitlab Enterprise Edition installed. I did perform a backup of my old system however I realized it was on Gitlab EE 15 and current is Gitlab EE 18. When I tried to locate the v15 software, it’s so old that it’s unavailable.
Realize that the whole point of git itself is everything involved in the project is on everyone’s computer. So I made the decision to just install the current version of Gitlab EE v18, and simply recreate all the Projects.
There are some 45 Projects spread across four systems but again, they’re all complete.
What’s the loss then? Mainly the Pull Request history itself. When you commit a change to your code, you probably created a short log entry. The Pull Request is handled by the overall tool, Gitlab in this case. You can provide a more detailed description of the change, you can see a graphical representation of the branches and who approved the Pull Request. There are other parts in a more production like environment that are also missed.
In my case though, it’s just me learning how CI/CD works and the effort to locate the v15 software and then perform upgrades, is a bit unnecessary. So I created all the git projects I’d been working on and loaded them into Gitlab.
Next up is getting Gitlab Runners in place and installing Jenkins and the two Jenkins agents. Then the actual CI/CD process configure.