I Tried Implementing Continuous Integration/Continuous Delivery (CI/CD): Did it boost my efficiency?

Generic CI/CD or DevOps pipeline setup

Introduction:

There is always room for automation if the task is repetitive, and I was looking for a way to delegate all the chores that I needed to do to a cloud server that does everything when I push my changes to the project repo.

I was skeptical of the hype surrounding CI/CD. All that automation and all those pipelines seemed like an unnecessary hurdle on the path to getting things done. But I was tired of the manual testing, the merge conflicts, and the last-minute scrambles before deployments. Efficiency was suffering, and something had to change. So, I took the plunge and implemented CI/CD in my workflow. Did it pay off? Buckle up, fellow developers, because I’m here to spill the tea.

The Initial Struggle:

Let’s be honest, setting up CI/CD isn’t a walk in the park. There’s a learning curve, a configuration to tackle, and the inevitable bumps along the road. Choosing the right tools, getting everyone on board, and ironing out the kinks took time and effort. But hey, no pain, no gain, right?

The Efficiency Revolution:

Once the dust settled, the magic started to happen. Here’s how CI/CD transformed my efficiency:

1. Automated Testing: No more tedious manual testing! Automated tests run with every commit, catching bugs early and often. This saved me countless hours and headaches down the line.

2. Faster Feedback: Every push triggers the pipeline, giving me instant feedback on the health of my code. This helped me identify and fix issues before they snowballed into major problems.

3. Streamlined Deployments: Gone are the days of manual deployments fraught with errors. CI/CD automates the deployment process, making it faster, safer, and less prone to human error.

4. Improved Collaboration: Version control and automated builds ensure everyone’s on the same page, fostering better collaboration and transparency within the team.

5. Peace of Mind: Knowing that my code is constantly tested and deployed with minimal effort gave me a newfound peace of mind. I could focus on writing good code instead of worrying about the deployment process.

Free CI/CD with GitHub and GitLab:

One of the biggest advantages of adopting CI/CD is its accessibility. Both GitHub and GitLab offer free plans that include basic CI/CD functionality. This is fantastic for individuals, small teams, or open-source projects starting their CI/CD journey.

With GitHub Actions, you can create basic automated workflows for building, testing, and deploying your code. Similarly, GitLab CI/CD allows you to define pipelines for running tests, building artifacts, and pushing them to desired environments. While their free plans have limitations compared to paid tiers, they provide a solid foundation to experience the benefits of CI/CD without significant upfront costs.

GitHub offers free CI/CD for public repositories through GitHub Actions. GitHub Actions can also be used for free on private repositories for up to 2,000 minutes of hosted workflows per month. If a developer hosts their own GitHub Action server, there is no limit to the number of minutes.

GitHub Actions is free if jobs execute on standard GitHub-hosted runners in public repositories or if you host your runners yourself.

GitLab offers free CI/CD for public, open-source projects on GitHub. The free tier of GitLab includes basic features, such as:

• 5 GB of storage
• 10 GB of data transfers per month
• 400 CI/CD minutes per month
• Five users per namespace

Vercel CI/CD integration into your favorite source code repositories.

Vercel has simplified the setup process to just one button click. I won't lie, it's been a breeze to just use the Vercel CI/CD pipeline. In my experience, it is one of the best ways to set up a CI/CD in a matter of minutes. and deploy your code with ease. The way Vercel builds your branch or a pull request and deploys it to a live URL is an incredible time saver since you can just open the URL and see the changes without having to manually run the project locally and test it out.

To try it out, just head to https://vercel.com/new and click that big deploy button to deploy your project.

Note: Now, when you are working on a project, you need to select a particular branching model since you can’t, and YOU SHOULD NOT, work in the main branch. The branching model that we are going to use is called Gitflow and is used widely in multiple projects. All code changes should be merged into the developbranch for this to play out nicely. When you are finally confident enough to do the final release of a major feature, you can merge the code into the mainbranch, and it will be deployed in a matter of minutes.

Here is an example of a GitHub action file that describes how to build the Python application, and it’s run every time the code push event occurs. It also includes steps for testing and creating the build artifact

name: Example Build Python App
on:
  push:
  #Event that triggers a build, a push to the main branch
    branches:
      - main
env:
  environment: Prod 
jobs:
#The list of jobs the workflow will execute
  build:
    runs-on: ubuntu-latest
    #Runner that the job runs on, ubuntu in this case
    
    steps:
    #List of steps which will be executed by the job
    - name: Checkout code
      uses: actions/checkout@v2
      #Action that checks out the code from the repository
      
    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: ${{ vars.python_version }}
        #Variables can be populated from the github repo variables
    - name: Install dependencies
      run: |
        pip install -r requirements.txt
        pip install ruff pytes
    - name: Build
      run: python setup.py build
    - name: Test with pytest
      run: pytest tests.py --doctest-modules --junitxml=junit/test-${{ env.environment }}-results.xml
      #Env Vars can be populated from the job itself
    - name: Upload pytest test results
      uses: actions/upload-artifact@v3
      #Artifact created from previous step is uploaded in this action
      with:
        name: pytest-results
        path: junit/test-${{ env.environment }}-results.xml

An image showing the results of automated checks on the pull request:

Head over to https://docs.github.com/en/actions/quickstart for more concrete information.

Beyond the Free Plans:

As your project grows and your CI/CD needs evolve, you can explore paid plans on both platforms. They offer features like:

• Increased build minutes: more time for complex workflows.
• Parallel builds: faster execution times.
• Advanced caching: improved efficiency and cost savings.
• Integration with external services: streamlining your development process.

The choice between GitHub Actions and GitLab CI/CD comes down to your specific needs and preferences. Both offer compelling free plans and powerful paid options, making them excellent platforms to leverage for your CI/CD journey.

Not All Sunshine and Rainbows:

Of course, it’s not all sunshine and rainbows. CI/CD isn’t a magic bullet. Here are some of the challenges I encountered:

1. Time to set up: Setting up CI/CD requires time, effort, and sometimes financial investment. But trust me, it’s an investment that pays off in the long run.

2. Maintenance: Like any system, CI/CD pipelines need maintenance and upkeep. But the benefits far outweigh the effort involved.

3. Learning Curve: There’s a learning curve associated with CI/CD tools and concepts. However, plenty of resources are available to help you get started.

The Verdict:

So, am I more efficient now? A resounding YES! Implementing CI/CD has boosted my development speed, improved code quality, and reduced stress. It’s not a silver bullet, but it’s a powerful tool that can truly revolutionize your development workflow. If you’re on the fence, I urge you to give it a try. You won’t regret it!

Remember: This is just my experience. Share your own CI/CD journey in the comments below! Let’s discuss the challenges, the wins, and everything in between. Happy coding! 💪