Alright, so, as of last time, we have our basic GitLab instance installed and working. I’m not going to go through exactly “How do I Git” or “How do I GitLab” right now, but there are lots of good resources out there. Googling is useful, but I’d start with the GitLab Basics Guide. A later post will go in to my take on those topics and more importantly, how to use Git with LabVIEW.
So for now, let’s dive in. We’re going to do a few things this time:
As of last time, we finally have a Hyper-V server with a copy of Ubuntu server on it. Now let’s actually make it in to something useful. We’re going to install a copy of GitLab Enterprise Edition on it, and do some basic configuration. Stepping back for a moment, however, why GitLab EE?
Most of the content here is not applicable if you are going with a cloud-based solution.
I’m a huge fan of virtual machines. For those not familiar, VMs are essentially a way of running a completely independent OS inside of another. (Note that this shouldn’t be conflated with containers, which are similar but share underlying components with the host OS. More on that in a future post in this series.)
Hyper-V is a hypervisor created and distributed by Microsoft. In it’s simplest sense, a hypervisor is simply a platform for running virtual machines. I’m a huge fan of Hyper-V for a variety of reasons, some technical and some logistical, but I do feel compelled to point out that there are other solutions out there, such as Oracle’s VirtualBox and a variety of options made by VMWare. Today though, let’s just talk bout Hyper-V.
Note: This the introduction to a series of posts on building your own DevOps infrastructure.
So, everyone knows that source code control is mandatory, unit tests are great. And hey, that thing called continuous integration? Yeah, you should be doing that.
When done properly, the results are fantastic. But let’s be honest… how many of us actually have the infrastructure in place for all of this?
Here at Hiller, we already do a good job of SCC, but we’re embarking on a journey to implement a full DevOps solution. Now, there are already a variety of resource detailing how you can do most of this, but we have a twist, as we must have provisions to be ITAR compliant for many of our projects. As such, we can’t use GitHub Enterprise, the cloud version of GitLab, or many of the other solutions out there.
Develop and discuss a solutions for automated testing
As we go, I’ll generate blog posts on every step of the way. You can watch for posts with the “DIY DevOps” tag, or just keep an eye on this page, which I’ll edit and post links to new entries as I make them.
For reference, we’ll be hosting everything on-prem (at least initially). In my posts, I’ll try to make note regarding the differences between a cloud-based approach and what we’re doing (and how we may partially migrate to a cloud based approach down the road).