I have been working with a build pipeline using dependabot this year. At the start of 2019 I took over as team lead on a project. My predecessor had enabled dependabot across the teams pool of repositories. After some pruning we have around 60 of these.

Dependabot is an attempt to solve the upgrade cycle for third party dependencies. It will create a pull request for each new version. If you have a build server configured to run tests that you trust then you can get dependabot to auto merge the passing changes.

The year started with a backlog of 360 PRs. Early in the year I spent the first part of each morning ensuring that almost all of the projects have at least a test pipeline..

This started to make an impact on the backlog. We then encountered our first react update. This added 70 PRs overnight.

One pair on my team automated the deployment of the react libraries to our CDN. This eventually helped (we did have a fun problem with the first bad deploy – if you deploy a bad version of a library to a CDN then its painful to correct – some users will have that version cached potentially forever).

We also needed to restart a lot of broken builds. CD is great but sometimes.cloud infrastructure just fails

Dependabot has a helpful interface in that it has an agent that responds to comments on a PR. This allows you to tell it to rebase/recreate/ignore/merge things.

This week we got the PR total down to 12 by the end of one day. The next day Babel released a new version so we jumped to 70 …

We will never win this race but Dependabot does help keep the code upto date. Note we also get updates from other teams in the organisation. One morning during planning we were able to report that a change we had been waiting on had been released, tested and merged in the time we were meeting.

I have had to raise a few issues with Dependabot support and they did fix them quickly. They had not experienced organisations with over a thousand repos before which made the configuration UI slow – this in now much better.

Our setup of Dependabot, Jenkins and Github did not react well to the introduction of Snyk to the system. Snyk tells Github that it is happy with the security of the dependencies. The problem was this was faster than Jenkins telling Github that it had started testing the change! Dependabot then saw a PR with an ok stamp and then merged the change. We had a fun few days reverting broken builds until we tamed that one.

During the year Dependabot was bought by GitHub and is now free to use.

For now I have disabled Snyk on our projects but will investigate it further in the new year (it appears less configurable than Dependabot).

Here’s to another year of upto date dependencies.

Tea requires boiling water (100C) to brew properly. Giving me a pot of hot water and a tea bag will not allow me to make tea.

I currently work with a project that is controlled by a configuration file.

It has become useful recently to write unit tests for the config file.
We check simple things such as duplicate and even validate keys against a public api.

Given that we are integrating with over 100 services a mistake can cause a large amount of errors. Unit tests help here.

I gave a talk last night at London Functional (hosted by Funding Circle) on Exercism.io and Elixir. During this I attempted a live coding demo.

This had been practiced earlier in the day. I make the typical mistake of trying to make a last min change without retesting. One part of the demo failed. Lesson for the future – don’t change a working demo on the day of a talk!

This looks to be useful:

https://github.com/jan-molak/serenity-js/blob/master/docs/screenplay-pattern.md

I have been mentoring Elixir on Exercim.io for over a year now.

In that time I have mentored 4903 solutions across Elixir and Groovy.

This is a great way to keep your skills upto date in a language.

The students will challenge you with details that you will need to research. It’s the questions that you get that will stretch your knowledge.

You will need to explain unusual bugs and concepts to people who may not have english as their first language.

The UK is in the middle of a program to implement Smart Motorways on various M and A roads. The intent of these is to allow the hard shoulder to be used as a normal lane except in the event of an accident whereby the variable speed limit signs will mark the lane as out of operation. This seems like a smart idea until you realise the competence of the current variable speed limits.

Variable speed limits can only work if the traffic is capable of travelling faster than the proscribed speed. They can only slow the traffic down. If the variable speed limit is set above the current speed of the road then it is wasting it’s time. This is the majority of uses of the variable speed limits. In addition these limits are kept in place far longer than the problem exists. I have frequently travelled through speed restrictions on the M25 where no broken down car or lose animal was visible. I call the problems these cause artificial traffic jams.

We have an organisation controlling the speeds on motorways that seems unable to reliably determine that a problem has been resolved. Given that this is a similar problem to detection when a breakdown has happen we will have no hard shoulders and traffic just breaking down on the roads.