Background

I love automating boring things, and that’s why I got into programming. When I then first heard of devops I got quite excited, as it automates parts of the software development life cycle, allowing for continuous integration/continuous deployment.

Though I’ve only explored some basic devops practices and really haven’t covered the full spectrum of available tools, I wanted to share what I’ve learned and have been able to implement on my hobby projects. For demo purposes I used my lilypond-web github repo, which I have a separate post that describes what this repo does (which is a simple web service that converts lovely LilyPond code into music scores!).

The tools that I’ve implemented and am covering in this blog is CodeFactor, CircleCI, Codecov, which can all be found on the GitHub marketplace free for open source projects and repos:

Setup for github repos

Continuous Integration (with CircleCI)

Quick overview of the Continuous Integration practice (cherry picked from wikipedia):

• Maintain a code repository
• Automate the build
• Make the build self-testing (tests like these have to be written first!)
• Commits should be built and tested before it is deployed (either in master or other branches).

To achieve this with CircleCI:

• Add this to your github from the GitHub marketplace

• Add a file in the repo:

  • .circleci/config.yml

  • For a python project, the file should look similar to the template below (also see an example in my github repo:

  version: 2
  jobs:
    build_and_test:
      docker:
        - image: circleci/python:3.8.0-buster
      steps:
        - checkout
        - run:
            name: step 1, e.g. install requirements
            command: pip install -r requirements.txt
      
        - run:
            name: step 2, e.g. run the tests
            command: python -m unittest
    
  workflows:
    version: 2
    build_and_test:
      jobs:
        - build_and_test

There are more options on the CircleCI dashboard to adjust, and you can alter the .yml file to your needs, but a config file is all you need for a basic CI pipeline, which is set to run when commits are pushed.

Benefits of CI:

• Automated test pipeline makes code more robust as it will prompt you from releasing breaking code (assuming enough test coverage!)
• Code development can be made easier (if code is more modular, it is easier to test)
• Easier to debug (check which test is failing and attend to that part of the code)

After the CI pipeline is set up for automated builds and tests, more components can be added to this pipeline. One very useful thing to add is some analysis of the code quality and test coverage, which are described below.

Assessing test coverage with Codecov

To add a code coverage report:

• The python unittest needs to be run with the coverage package to create a test coverage report
• This report can then be read by Codecov, which has a nice interface that shows which lines of code are not covered

To incorporated these steps to the build and test CI pipeline from above, there are two things to do:

• The .yml file requires some modification:

  version: 2
  jobs:
    build_and_test:
      docker:
        - image: circleci/python:3.8.0-buster
      steps:
        - checkout
        - run:
            name: step 1, e.g. install requirements
            command: pip install -r requirements.txt
      
        - run:
            name: step 2, e.g. install test and quality check packages
            command: sudo pip install coverage codecov
      
        - run:
            name: step 3, e.g. run the tests
            command: coverage run --omit="*/test_*.py" -m unittest
      
        - run:
            name: step 4, e.g. upload the test report
            command: codecov
      
  workflows:
    version: 2
    build_and_test:
      jobs:
        - build_and_test

• A Repository Upload Token needs to be obtained from codecov, which can be found in https://codecov.io/gh/<user_name>/<repo_name>/settings). This needs to be added as an environment variable in the CircleCI settings (found in https://circleci.com/gh/<user_name>/<repo_name>/edit#env-vars)

  • This is required to inform CircleCI where to send the coverage report to

Assessing code quality with CodeFactor

There is a spectrum of good and bad ways to write code that can carry out the same desirable process. One extreme (the bad side) is writing code that runs today, but the code itself is completely not understandable when reading it again after a month. On the good side, if general software engineering practices and principles are applied, the code quality can be made much better, which CodeFactor can be used to provide such assessments. Factors that are taken into account include maintainability, readability, reliability, modularity, reusability. One can learn a lot just by getting these code quality reports to know how to adapt better coding practices!

Adding this function with CodeFactor is easy. After registering and logging into CodeFactor, Just go to https://www.codefactor.io/repository/new and add your repository so the CodeFactor can access and assess it.

Showing badges on your repo

Each of the above tools provide badges for each project that you have scanned, which I find very useful to show on the readme files of my github repos. I suppose one can use these to show off, but for me it is a good reminder that enforces me to try maintaining good coding standards (and providing myself a certain degree of satisfaction and achievement)

The badges are easy to find in your correponding repo project settings in each tool’s dashboard page:

• For Codecov: https://codecov.io/gh/<user_name>/<repo_name>/settings/badge

• For CircleCI: https://circleci.com/gh/<user_name>/<repo_name>/edit#badges

• For CodeFactor: https://www.codefactor.io/repository/github/<user_name>/<repo_name> (click on the badge near the top right of the page)

And these can be added easily to the readme, resulting in something like this:

Tool	Badge
CodeFactor
CircleCI
Codecov