Integrations, code, and the oxford comma

Note:

This is the Introduction, in a multi-part series.
Here are the other parts that you should probably check out as well:

Back in the day, building a website wasn’t all that dissimilar to building any other design project, at least in my case. The usual process went something like this:

  • Make a folder on your local computer
  • Dump all work files into that folder
  • 🦄🦄🦄
  • Profit?

Somewhere along the line, you had to eventually work with another person on making changes to that same site. That usually involved throwing your files onto a server and each person downloading the files to their own machine, and then pushing them back up when they were done. Or sometimes, directly working off of the server (if you were in the same office.) Yeah, it was super tedious. I got used to my FTP client working overtime to try and keep up most of the time.

Sure, it didn’t always work well. Sure, there was a bit of “manual” versioning of files (ie: file_v1.html, file_v2_r43.html, file_v33124_DEARGOD_MAKEITSTOP.html, etc), but it wasn’t that bad, right? Yeah… so obviously it wasn’t a sustainable practice, even at that scale. There had to be a better way, right?

via the amazing teaandbuns on Etsy

Enough with the acronyms already

There were always CVS/SCM systems, but those were for super nerds. Revision control/source control systems were complicated and only people that worked in academic environments or Linux nerds actually knew how to use them. We all know where it went from here. Options like Mercurial, subversion and other VCSes started to pop up, along with services that hosted these repositories for you. (There’s a long history of VCS nonsense out there, I’m just verbalizing a general overview here…)

So, eventually ALL THE THINGS seemingly went to Git thanks to the Linux community (yeah, that BitKeeper controversy was a good thing, right?) and sites like Github – that made it easier to demystify the whole process and visualize what your files were actually doing. Throw in GUI clients, and morons like myself could actually use this stuff.

Coming from subversion, Git/Github was great. I lived my life happily checking in code every so-often and would pull it down when it needed an edit or two. I even worked with other developers on various codebases and it just worked! But that’s all that I really did with it. Code lived on Github and occasionally got pulled/edited/merged back to the repository. I was never really into tackling anything more with it, but then along comes this goddamn CI stuff.

“Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository, several times a day. Each push is then verified by an automated build process, allowing teams to detect problems early. By integrating your code regularly, you can detect errors quickly, and locate them more easily.”

There’s more about all this CI stuff from people smarter than me here and here, if you’re curious.

Fast forward to the present

I’ve user other CI setups like Jenkins and circleci over the years on various projects, I wanted to host my own CI server on my Homelab to see what I could do with it, what the limitations were, and if there really was something to this whole “code checking” thing (mostly on smaller projects). I have a fair share of personal projects that I already host on Github, but was it worth it to put a CI implementation on something that doesn’t necessarily need the checks that larger projects require? That’s what I set out to answer…

In my research, I came across a few CI options, and listed my considerations of each:

  • TeamCity - We ran this on a dedicated box for awhile (at BaM) and I didn’t use it much back then. Honestly, I never looked into this at all, as I picked another option before finishing my research.
  • Gitea - More of a complete Git solution. I was just looking for something that plugged directly into a Git flow from Github, since I’m already established with my repos over there.
  • Gitlab CE - I ran a complete Gitlab CE for awhile in virtualization. Setup was straightforward for the app itself (using Docker), but getting the workers (as other Docker containers) integrated proved to be difficult out of the box. Throw in running a reverse proxy to complicate things, and it just seemed like it wasn’t worth it. I have not tried to use their CI workers on the Gitlab site, but I’m sure those work fine.
  • Jenkins - Highly rated and recommended across the board. This was my next goto if I didn’t settle on a solution prior to checking this out. I might go back and look into it if I ever grow out of my current solution.
  • Bamboo - If I was a full-time Bitbucket user, this might make sense. Free for 30 days, then $10/mo. Since I was looking for open source, this wasn’t a fit.
  • Drone - Minimal website, minimal documentation. Sure, why not. This is what I landed on, mostly due to a relatively simple deployment/setup (so I thought). I am a glutton for punishment.
  • Semaphore - Per-second pricing seems like a great idea once I know what I’m doing. $20/mo free credit (1,300 service minutes) is a solid deal, especially since I could run parallel pipelines. Since it charged, I didn’t even consider it. Also, not a local install.
  • Codeship - Another non-hosted solution, which is fine, but I was looking for self-hosted. Forever free (100 builds/mo free, with unlimited projects and unlimited team members) is nice though. Worth checking out if I get sick of self-hosting.

I’m sure that there are thousands of other CI options out there, but this was the initial list that I investigated. In the end, I landed on Drone, mostly because it seemed like the most basic use-case for my needs, and was simple enough to setup and get started with. But man, there was sure a steep learning curve involved, having never used/written testing for applications that I was developing.

Now, I don’t claim to be a master backend coder. In fact, it’s mostly been hobby programming projects and learning as I go, on most of my previous projects. I’m a frontend guy by trade, but I’m usually determined to learn how a lot of this stuff works, and try to make it my own. So… I dove in head first to this CI stuff, determined NOT to let myself drown in the process.

Imma let you finish, but…

Also, in reference to the title of this post, the Oxford comma

I’ve been a firm believer that it wasn’t ever needed in a sentence. For 42 years (or rather, the amount of time I’ve actually somewhat understood our English language), I’ve thought that the oxford comma was unnecessary. I’m not sure if I suffered a traumatic head injury lately, but lately I’ve been using it when I’ve been writing.

I doubt that it’s a maturity thing (I’m not, make no mistake) or if it’s just something that I stumbled back to organically, but I wanted to at least point out that it was a thing that I’m actually using oxford commas now. Maybe I’m turning into Kanye, or it’s just social media rotting my brain. Either way, odd stuff.

Continued in Part One »