Consider the Source

As a QA Engineer I’ve been a part of the software development process and certainly worked around source control solutions a lot. TFS, Azure DevOps, GitLab…I also had my own GitHub account for literally years…which sat there for most of that time practically unused outside of forking a repo here and there to look at like a raccoon looking at a flying saucer. It was beyond me. The code, and perhaps even more the version control magic that happened behind the curtain. I understood the rudimentary idea of what was going on (e.g. I knew what a pull request was) but as far as I was concerned that was a sky mission and I was Aquaman. 

That changed just a tiny bit recently when I took the QA course at Free Code Camp. The course covers front end and back end testing via Chai assertions, Node.js & Express (amongst other things). By the end you build a chat app that communicates between a server and connected clients, as well as a viable testing solution for it. 

That’s all fine and relevant to my current work but what I really enjoyed and wasn’t expecting was to run/test my coursework via a simulated environment set up through a source control. For this next part I ask for your patience & mercy as I might still mess up some of the terminology, but here goes…

To complete the course’s challenges you have to clone their QA course repo from GitHub. From there you had the option to:

• run the repo locally and complete the challenges
• run the repo/complete challenges on a hosting site of your choice
• related to the above, host the repo/complete challenges on Replit
• At the end, regardless – the solution would need to be hosted live somewhere for the completed challenges to be tested and the course completed.

All the above is a true story but doesn’t capture all the experiences it was to me:

• First time hosting an app
• First time setting up my own environment with my code running in VS Code, connected to the repo on GitHub, doing commits on the VS Code side and seeing (as the GitHub page owner) those commits come in on the other side to merge to the codebase. I always knew that stuff happened but I had never ran my own. It just hits different.
• With GitHub/Netlify connected, seeing that same setup described above only also seeing those changes replicate over to the Netlify platform. 
• When trying to set up on Netlify – having to modify files and create custom files to make it jive with Ruby. 
• Finally – setting up on Replit (“Replit is a simple yet powerful online IDE, Editor, Compiler, Interpreter, and REPL*. Code, compile, run, and host in 50+ programming languages.”)  where I could see my commits merging onto the codebase & showing up in the repo, rebuilding my app and seeing the challenges pass, and seeing the changes show up in the connected GitHub repo and VS Code when I re-synched. 

I always love seeing how things work under the hood. It’s why I prefer to watch a documentary on how a cruise ship’s water sanitation and desalination plant works rather than what their entertainment venues look like. In that context I would say that source control is somewhere between a Broadway show and sewage treatment. It stinks but can still be exciting and interesting, especially since the applications I work with can’t exist without it.