Debugging CI builds in Travis

Photo by Marten Newhall on Unsplash

Sometimes a Travis job fails and after looking through the output you have no idea why. The things are getting even more mysterious if the script works fine on the local machine. I’ve been there recently when had to debug a job running E2E tests.

There is a solution on how to debug a Travis job locally in docker container but there is a better and more reliable way – running Travis job in debug mode.

Launching Travis job in debug mode

To start a job in debug mode it should be enabled for GitHub repository. Things are way easier if your repository is private, debug mode is enabled there by default. Just navigate to the job page in the web UI and click the Debug job button at the top right corner to start.

For public repositories you have to send a request to support@travis-ci.com and specify the list repositories where you’d like to make debug mode available. It can take some time but needs to be done only once for the repository so it shouldn’t be a problem. I was lucky enough and my request was handled pretty fast (within several minutes).

Note: Switching repository from private to public will disable debug mode mentioned above. So you’ll have to send a request to support.

Once the debugging is enabled for the repository the only way to launch a job in a debug mode for a public repository is via API call. Here is the example with curl:

curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Travis-API-Version: 3" \
  -H "Authorization: token ${TRAVIS_TOKEN}" \
  -d "{\"quiet\": true}" \
  https://api.travis-ci.com/job/$JOB_ID/debug

As you can see there are two things required to send such a request:

  • Travis token. You can grab one from Profile > Settings > Settings tab on .

  • Job id. It can be taken from the Travis job page url – the numeric part at the end of the url. E.g. 123456789 for the url https://travis-ci.com/github/.../jobs/123456789.

Little hack: You can add the utility function to your ~/.bashrc:

travis_debug() {
  if [ $# -eq 0 ]; then
    echo "Job id is required"
    return -1;
  fi
  JOB_ID=$1
  curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Travis-API-Version: 3" \
  -H "Authorization: token ${TRAVIS_TOKEN-$2}" \
  -d "{\"quiet\": true}" \
  https://api.travis-ci.com/job/$JOB_ID/debug
}

Now to launch the job in debug mode run in the terminal:

TRAVIS_TOKEN= travis_debug 

// or

travis_debug  

Debugging the job

Once the job started in debug mode go to the job log and take ssh connection string, similar to this one:

...
Use the following SSH command to access the interactive debugging environment:
ssh DwBhYvwgoBQ2dr7iQ5ZH34wGt@ny2.tmate.io
...

Paste it into the terminal as instructed to connect to the Travis container running the job. Starting from here you are connected to the fresh instance and can do almost anything you want to debug the script like run commands one by one, change environmental variables, edit scripts or run custom commands and scripts.

To make things a bit easier Travis provides handy functions of format travis_run_ e.g. travis_run_before_install, to run scripts of a specific phase as per job config. See the full list of functions here.

It’s worth mentioning that the debug session is tmate session rather than fully functional terminal. Which means you can’t use things like scp to download files to your machine so other workarounds are required in case you need it.

Another unpleasant thing is that closing the session terminates the job and you’ll have to start debugging from scratch in case the session is accidentally closed. Follow these instructions if you need to keep debug session output on exit.

Besides that debug mode is super handy and can save you a ton of time while debugging and fixing failed jobs.

Happy debugging!

Why to test software

Photo by National Cancer Institute on Unsplash

> Why do we test software? Most people would say: “So we know it works.” > > — From this blog

I like this answer because it’s short, simple and matches my point of view 🙂 I do want to know the software I create works!

It takes time and effort to master testing skills and learn necessary tools. Many developers don’t write tests and they have their own excuses for it. And there’s a bunch of positions between these two poles: haven’t decided yet, just heard something, once tried it, but it didn’t go smoothly, etc. Anyway, before investing your time and effort IMO it would be good to know why and how testing can make your life better. Further you’ll find the benefits I see and utilize with tests.

Mistakes

Every developer makes mistakes. And it’s not because they are bad or inexperienced, but because they are humans and humans makes mistakes.

Moreover modern software is built incrementally by adding smaller changes and combining many independent units. And the more pieces the software has the higher is the probability to introduce a mistake with new changes.

=> Tests are our validators for the software. Creating more tests validates more scenarios hence reduces amount of mistakes left unnoticed.

Product quality

Product quality is a multidimensional topic. While stability is only one of the quality aspects it’s hard to overestimate its influence: it’s very unlikely you would call a product a good quality one if it constantly breaks while working or after each update. And vice versa we can say higher quality products are more stable and have less mistakes.

=> Tests reduce amount of mistakes and raise product quality!

Confidence

Developers are humans, I know I’ve already told this but this time it means each developer is a living person! And I doubt many developers are looking for stress and sleepless nights at their work due to buggy software or poorly tested product releases, constant fights with fires and so on. It might sound a bit dramatic and I haven’t been in such situations but I’ve read about them in the books (e.g. DevOps Handbook) and suppose it’s real.

Tests validate that software behaves the way it is expected. Running tests gives a confidence that expectations are valid, confidence reduces stress and less stress leads to a healthier and happier life. One really important thing here is the tests are useful as long as expectations described in the tests match the way the software should behave from the consumer point of view. Poorly written tests validate expectations meaningless to how software is consumed.

=> Running tests gives a confidence that expectations are valid, confidence reduces stress and less stress leads to a healthier and happier life.

Architecture

Software is not a building, its architecture changes and evolves during the lifetime. So it’s quite common to add functionality to existing modules, split large modules into smaller ones, break dependencies and rearrange the things. All those changes can potentially break some existing functionality.

=> Tests allow us to catch those regressions before they reach a production, making refactoring and architecture improvements more stable and reliable.

There is another way how tests can improve architecture if you run them before (TDD way) or right after the new code.

=> Writing tests forces developer to think about how to put the code under test and how is it going to be consumed leading to better code structure and modularity.

Documentation

Writing docs is not the most pleasant work for developers and they are usually not so good at it. It’s quite hard to maintain the docs up to date especially if they live far from the source code. Even if docs are written withing the code it’s quite easy to forget to update them once the code is changed just by mistake. On the other hand if tests are out of sync with code they fail and signal you that changes are required.

=> Tests are a good source of developer documentation with examples of how to use modules and how edge cases are handled by the software.

Time & Money

Everything above is correct for tests in general but why automated tests? Because the more features the software has the more cases have to be tested. And the more scenarios you test the more time, and mental efforts it requires from tester. Testers are humans as well and we’re back to mistakes ☝️. Scaling manual testing efforts is way more expensive as compared to scaling computational resources for automated testing.

On the other hand machines are way faster and better than humans at doing mundane and repeating tasks. And most of tests are like this. Automated tests can be run super fast and very often providing all benefits mentioned above: less mistakes, better product, happier team, happier customers.

=> Automated testing allows to spend more time and money on innovations and improvements by saving costs for maintenance and bug fixing.

Conclusion

Real software might be complex and might have many various requirements that’s why there are many different ways to check the software works as expected. Automated testing is only one of the ways and it’s not a silver bullet. It has its own costs and tradeoffs and if done wrong can even harm the project.

However, mindful, disciplined approach, patience and practice pay back allowing you to get all the benefits mentioned above making it extremely hard to switch back to creating software without tests.

Make STOPs to steer your life with open eyes

Stop sign image
Photo by John Matychuk on Unsplash

Steering with closed eyes is not the best way to get to the destination. And I believe each of us is a driver with a “steering wheel” in the hands – the steering wheel of life. We have plans and we’re taking actions (or inactions) many times a day the same way as a driver has a route to the destination and choosing when to accelerate, stop and change the route. Ask yourself would you be happy if your taxi driver gets off the route, misses a turn or goes the wrong way? Probably not. While it’s relatively easy to look around and follow the route while driving the car it might be challenging to do the same with your daily life. 

TLDR; I’ve read about the tool called STOPs in the book “The Inner Game of Work” by Timothy Gallwey. I use STOPs to align with my plans and take actions in a timely manner. More details 👇.

Zooming in and out

In Google Maps you can zoom in and out to see more or fewer details on the streets and roads. Depending on how far you go you might need to zoom out to fit the whole route. However, you should zoom in to get detailed directions to the destination while driving. Moreover, if the route is unfamiliar Google Maps can make life easier by tracking the position, notifying on required actions and suggesting alternative routes.

The same way any higher-level goals and plans can be split into smaller tasks and milestones. The same way precise steps need to be taken to get the result. However, following own plan is hard because there is no such Google Maps for it. You should manually zoom in and out to check your current position on the route and correct the directions to reach the destination.

Execution inertia is your enemy

Besides our plans and goals, so many things break into the daily routine from different sources like family, coworkers, communities, friends, etc. We are going through hundreds of messages, calls, posts, tweets, meetings and so on. We’re creating task lists to keep things organized and under control.

Even if you apply task and time management tools it’s so easy to get into a trap of unconsciously executing one task after another without realizing the importance of the task or how is it related to the higher-level goals. This is what is called execution inertia. It keeps you driving full speed in the flow of daily tasks without giving a chance to check the directions on the map.

STOPs to the rescue

I’ve read about the tool called STOPs in the book “The Inner Game of Work” by Timothy Gallwey.

STOP is an abbreviation of four steps:

  1. Step back.
  2. Think.
  3. Organize your thoughts.
  4. Proceed.

Step back. It is a crucial element of the tool. First of all, it requires you to take a pause and step out of the flow of tasks. Then you have to zoom out to create a different perspective on the current situation.

Think. Once zoomed out you can better observe the current position and direction, analyze it and compare with the desired route. Just draft some thoughts and ideas at this step.

Organize your thoughts. While the previous step can bring a lot of insights and interesting ideas, this step is required to update the existing plan or make a new one.

Proceed. You’ve already done a great job at previous steps! It’s time to get back to the refreshed tasks flow 😉

Different flavours of STOPs

All STOPs shouldn’t be the same. You have a lot of freedom regarding when and how many STOPs you wish to make. They can be done during the day (e.g. start, middle, end of the day), once a week, month, quarter, etc. The duration can vary with the frequency of the STOP and depending on how far you zoom out when stepping back.

At the moment I have daily and monthly STOPs. I try to check the monthly plan a couple of times a week just to keep it in mind during the daily STOPs. And I check the quarterly plan during the monthly stops. 

In my opinion, it’s not that important how many STOPs you have. The key point is to get most of them for yourself.

Bring structure to chaos with Pomodoro technique

Photo by Tristan Gassert on Unsplash

There is no such a thing as time management because you can’t control time. However, you have ability to choose how you use your time.

I’ve come across this idea ☝️ several times for the past couple of months. The wording was different but the idea remains the same. Well, it sounds simple as many great ideas but how do you apply it to your daily life? How do you leverage this knowledge when your day is packed with lots of different activities, communications and interruptions?

TLDR; I use Pomodoro technique to split my day into focus slots. If you want to find out more on how I use it keep reading.

Focus, focus, focus

As it was said many times, context switching kills productivity so staying focused is a solution to the problem. And for developers who often work on complex problems it is very important to be in a flow state with high focus and concentration. To reach that state you need to eliminate as many distractions as possible and it’s not that hard to achieve if you work remotely from the home office like I do. But there is another trap in the full focus mode – it is so easy to spend too many time focused on developing software that I can completely forget or miss other things I wanted to do. And this is where Pomodoro technique come to the rescue.

Managing your day with pomodoros

Okay, I want to be focused for some time but not too long just to keep other things on track. This is exactly what Pomodoro is about:

  1. Pick a task and set a timer (25 minutes is recommended). One slot is called Pomodoro.
  2. Work on the task without switching and distractions.
  3. Take a break. Recommendation is 5 minutes after each Pomodoro and 15 minutes after each fourth Pomodoro.
  4. Go to step 1.

Idea is super simple. This allows you to structure your day into finite amount of focus slots and you have a choice which activities you fit into the slots. On the other hand, Pomodoro just gives you a framework routine and it’s up to you how to use it. Recommendations above are good enough to start with but they may be not ideal for a particular daily schedule or activities. So some adjustments might be required and the good thing is nobody forbids doing so. Believe me, there is enough space for experiments and here are mine Pomodoro hacks:

  • I spend at least one Pomodoro at the beginning of the day for planning: catching up with updates (emails, chats, etc.), creating todo list, prioritising and “distributing” tasks into slots.
  • I experiment with the size of the slot for different activities. E.g. 55 min slot for development tasks with 5 min break works better for me.
  • Use breaks more effectively:
    • Quickly check chats during some of the breaks and update todo list.
    • Make STOPs (will write some post about it later) during the breaks to check how I am progressing during the day.
    • Do real breaks, move around, take a glass of water, tea, etc.
  • Combine multiple small tasks into a single slot. It’s just more efficient when you’re focused on handling multiple small tasks altogether.
  • Have some free slots without any tasks scheduled to fit in emergency activities. But I have a pool of some low priority tasks in case there are no urgent tasks.
  • Allocate some slots even for such things as random search and non-work related activities.
  • Allocate slots only for the type of activity rather than precise task. E.g. when planning I don’t try to guess how much time a specific task will take I just allocate some slots for development, code reviews, communicating in chats/emails, reading posts, etc.

Tools

At the moment I use PomoDoneApp for timers both on Mac and iOS, it’s free for my use case and has many configuration options which is nice for experiments. I use Todoist for task management and there is an integration available with PomoDoneApp but I’m not using it because of the reasons mentioned above.

Before switching to PomoDone I used Be Focused for Mac and iOS. There is a free version with annoying ads and without synchronisation between Mac and iOS. I decided not to use it because I constantly missed the timer on the phone because of the vibration only and I had to buy two apps (Desktop and mobile) to make synchronisation work.

Final thoughts

Pomodoro technique helps me to set time boundaries between different activities I schedule for the day and stay focused while working on each.

I have to say it wasn’t that easy to apply the Pomodoro technique to my daily routine. Sometimes I still forget to enable the timer or ignore the end of slot signal when I need some more minutes to finish the task but now I definitely have way more control and structure in my daily chaos.