ryer.io

Navigating the Journey from Interviews to Monorepos

#career #software #engineering #git #docker #hosting

TL;DR

  • Conducted a pivotal interview that might align my career with GitLab’s values.
  • Consolidated multiple web projects into a single monorepo.
  • Tackled issues with Git and Docker configurations.
  • Streamlined deployment using GitLab and Railway CI pipelines.

Today has been an absolute whirlwind. After completing my final GitLab interview with Tim Zellman, the VP of Engineering for the AI group, I’ve been in a state of both excitement and anxiety. The interview marks the culmination of a hiring process that could potentially lead to a role in the Workflow Catalog group, which is part of the AI department handling the presentation of AI data. GitLab’s values resonate deeply with me, and this opportunity could truly be a dream come true.

In order to focus my thoughts during this waiting period, I decided to streamline my personal projects by consolidating them into a single monorepo. Previously, my projects included a timeline website featuring a Go backend and Remix front end, a single-page Next.js site (soon to be converted to Vue), and a Hugo static site generator facilitated by a Python application.

Here’s how I executed the transition:

  1. Preparation: Recognized that the key was capturing all project histories. I first decided on a project to act as the parent directory. After some back and forth, I chose an existing project to house the others as subdirectories, maintaining its Git repository as the primary.

  2. File Management: I moved the projects into subdirectories using the command line, ensuring full inclusion of all files from .git folders to hidden files. Utilizing mv and glob patterns, I carefully structured the new hierarchy.

  3. Git Configuration: Initialized the monorepo by merging individual project histories into the main repository. Each project’s existing Git remotes were added as new remotes in the master repository. I used:

    • git remote add to link sub-projects.
    • git fetch to pull histories.
    • git commit to ensure a clean starting point in the monorepo.

  4. Resolving Conflicts: Addressed Git’s unwillingness to house nested repositories by removing redundant .git directories and avoiding submodules for a cleaner process.

  5. Deployment Setup: Reconfigured deployment with updated GitLab CI/CD scripts tailored for seamless deployment via Docker on Railway. This approach capitalized on GitLab’s pages and utilized parallelized CI to handle the different web applications in unison.

While technical challenges arose, such as hosting disparate technologies under a shared top-level domain and contending with Vercel and Docker configurations, I found these hurdles rewarding to overcome. It was a great exercise in meticulously distilling complexity into refined solutions, which I hope will become a standard practice in my development journey.

Now, as I await feedback on my GitLab interview, I find comfort in knowing that I’ve taken proactive steps forward, both professionally and personally. Here’s hoping both pathways bloom into new, exciting ventures.