Day 5 of My 180-Day Developer Challenge: Asking "Why?" Makes Every New Skill Easier to Learn

My Secret to Tackling Tough Topics: Always Start With "Why?". Whenever I learn something new, I first look at why it was needed in the first place. If you ever encounter something difficult or complex. Just research why it was created and adopted in the first place. After that, It would be much easier to learn something.

For example, You might want to know about cloud computing. Why was cloud computing was adopted? To make hosting easier and quicker - you could get any kind of machine you want. It could be a fserver, database, CDN, cache or backup. If you learn from that perspective, You instantly know why this service exists in the first place: why SSH key pair, why expose an IP address, why choose an OS or region. There could be a better example, But you get how easy it is to learn with that approach.

I started learning from this perspective to give myself a creative approach to technology or service. I would rather explore 10 different things about a new service rather than stress about it. It really makes sense when you realize that this technology is meant to make things easier for you to use. It could be simple, yet a lot of people just learn for the sake of learning or putting a new fancy thing on resume. Now i will explain, How i learned CI with some past history, theory and by taking action.

I want to share how people were dealing with a lot of pain integrating code, so you'll also understand why people adopted CI in the first place.

Scenario: Imagine you are a maintainer of a project on GitHub (or any other platform). Someone just made a pull request (~300 lines of code). There are some ground rules you've set as a maintainer - there should be 2-space indentation, some extra linting rules, and a few design patterns you've chosen. But to approve that piece of code, here's what you need to doe.

1. Clone the branch of the pull request.

2. Install all the dependencies.

3. Check for spacing, naming conventions and other linting rules.

4. Verifying every public function has a docstring or comment. Run each test and more…..

There are more problems that i didn't even mention like at least a week of wait for merging (It takes time for manual check), sudden outbreaks in production, or bugs popping out of nowhere and you're the one being blamed for it. It's a nightmare for a large team and a big codebase.

CI (Continuous Integration) came into the picture as a solution. There are many tools you can try, like Jenkins, GitHub Actions, GitLab, etc. For familiarity, I'll go with GitHub Actions. GitHub gives you about 2000 free GitHub Actions minutes per month. It could be more or less, comment down if it's different.

To make automated tests, you would need a machine -  Github would run a virtual machine just for the tests on a single pull request. It's a virtual machine with the operating system of your choice ( usually Ubuntu is prefered ). The repo gets cloned and dependencies would be installed with 4–5 lines of code. Then your actual tests run - Linting, Security checks, Unit tests, Integration tests, Cross-Platform Tests, etc. After that, you can just check whether the issue was resolved by that code. Then the job is done. Maintaining a project is still a lot of work as a maintainer, but CI makes the job much easier with automation.To create a CI tests in your repo. These are the steps:

1. Create a .github/workflows directory.

2. Create CI.yaml or CI.yml file ( either works, but yml is prefered)

3. Write your own file or copy this for a skeleton code and Commit the file

name: ci

on:
  pull_request:
    branches: [main]

jobs:
  tests:
    name: Tests
    runs-on: ubuntu-latest

    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: 18

      - name: Check node version
        run: node --version

Comment down your thoughts and if you found this helpful, Feel free to follow!!