My Devops Morning Routine
The first 30 minutes of my day that help improve my code day-to-day
I have been a developer for years, but during the last three years, I used to work as an Operational Service Manager in a feature team. My job was to make sure the service my team was providing was 100% available and functional. So it became a morning routine to check everything that happened during the night, chase all the 50X errors in our logs. We developed some tools to monitor and raise alerts on our service and all the services we depended on. Now that I am back to a devops position, it seems kind of weird to me to have less than 10 emails in my mailbox when turning my computer on in the morning. Why wouldn’t the developers have their morning routine, the habit they follow even without thinking of it to kick their day off?
The morning Script
One of the major issues developers have to cope with is technical debt. You know, the missing few details that are not blocking the delivery of user features so you delay and stack them up until the code has become an untested mess and you have to stop delivering features during one or more sprints to refactor, tidy up, whatever you call it, the code base. So I have written this tiny shell script that I call morning, and the first thing I do when I turn my computer on is run bash morning (which is kind of funny to me)
#!/bin/bashecho “Hey, morning!”source ../venv/SandboxAWS/bin/activatepylint ./pylibpytest -vv ./Tests/unit — cov-report term-missing — cov=./pylib
For those of you who are not familiar with python tools, this is what it does. The first line is the shebang to tell which shell to launch it with. The second line, just says “hi”. The third line activates the virtual environment, a temporary context in which I install a specific library or version of the library. it is a very useful and common tool, I guess you all use it if you develop with python.
The fourth and fifth lines are where the thing becomes interesting. The fourth line runs pylint (https://pylint.pycqa.org/en/latest/), a linting tool or as they write it, “Pylint is a tool that checks for errors in Python code, tries to enforce a coding standard and looks for code smells”. Their output is a detailed list of all the glitches they found in your code: Missing docstrings, unused variables, trailing whitespace, and so on. They also provide a mark out of 10 for the quality of the code they analyzed. The second tool, on line 5, is pytest (https://pytest.org). It helps write tests and run them. In this example, I run only unit tests (acceptance tests are run by our CI chain only as they are long and last more than an hour) and I also run the coverage module. The output of coverage is like this:
Name Stmts Miss Cover Missing------—--------------------------------------pylib\__init__.py 0 0 100%pylib\authentication.py 21 0 100%pylib\budget.py 58 25 57% 19–54, 60–61, 64–73, 78, 94–98pylib\cloudformation.py 59 34 42% 16, 19–21, 33–35, 42–53, 57–70, 76–80, 83–85, 89–91pylib\configuration.py 18 0 100%pylib\logger.py 3 0 100%pylib\referential.py 50 0 100%pylib\sandbox.py 50 27 46% 11, 14–17, 35–43, 46–52, 57–59, 62–68, 71---------------------------------------------TOTAL 259 86 67%
In the example, it indicates the modules that are fully covered and those that are not fully covered by tests. It also indicates the line numbers that are never called by the tests and thus the location of potential bugs. In the company I am working for, the expected level of coverage is at least 80% and here I am only at 67% for the targeted set of modules (the so-called pylib)
My Morning Routine
Before I start coding on the main feature I work on at this moment, I begin the day, just like karate katas or Tai chi movements by improving the correctness mark and the coverage rate by one tick every day. This is a simple continuous improvement and a lot of benefits in the long term. Pylint reported that ‘Your code has been rated at 6.65/10’, so I correct all the mistakes it listed to reach at least 7.65/10. It is very simple things, formatting or missing docstrings most of the time and it takes no more than 5 minutes. But it keeps the code in a good state of readability (it doesn’t correct design issues) and helps others to read it or me to get back into it after a break. It is a very good practice if you work in a team of developers. No debate on standards, comments, or no comments, the only rule is 10 out of 10 in pylint. That is the common standard we adopt.
For pytest, improvements are sometimes more complicated. There are quick wins. In the above example, in the last module sandbox.py, the first missing is a one-liner, line 11. Probably an exception that has not been reached and you then only have to write a test that is supposed to fail and test that it actually fails. When there are more than three lines it is a full method that has not been tested and should be covered before the debt becomes the Everest Mount! Here the full pylib has only 259 lines and is just starting so covering one single method pushes the coverage rate by more than one tick. Doing this every morning keeps your mocking and patching skills fresh in your mind and prevents those long and tedious moments when you have to stop coding only to write down tests because your last releases were nightmares and your manager is getting furious.
This moment should not take more than 30 minutes and it is a good practice to put your brain back into the project while sipping the first coffee of the day.
If you have some ideas to improve this routine, please share them in the comments below.
