Fully automated releases

Have you ever contributed a patch to an open-source project, got it merged, and then waited months for a new release that would include your patch? Me too, reader, I’ve been there.

Moreover, I’ve been the maintainer who hasn’t gotten around to cutting a release. Cutting releases is a chore. Usually it’s a fragile, multi-step process that is not especially fun.

As programmers, what is our answer to fragile, multi-step processes? We automate them.

How to do it

When creating a release, there are a couple of steps where human input and human judgement is needed.

1. When to create a release?
2. How much should the version number be incremented?
3. What to write in the change log?

There’s an automation-enabling answer to the first question that is familiar for many developers from their work environment: embrace continuous delivery and continuous deployment. Each pull request should leave the project in a state where it can be released. Then you can automatically create a release every time you merge a pull request.

You still need a human to answer the second and third question, at least if you have a conventional versioning scheme. To move the burden away from the maintainer, you can ask the contributors to fill in this information during the contribution process.

I know of two actual implementations of this: Hypothesis continuous release process and semantic-release. Hypothesis asks you to include a special file in your pull requests that looks like this:

RELEASE_TYPE: minor

This release adds a function for printing the text "Hello, world!".

semantic-release relies on specially-formatted commit messages:

feat(core): add function for printing ”Hello, world!”

Here feat means this commit adds a new feature, implying a minor release if you’re following Semantic Versioning.

In both cases, after a pull request has been successfully merged, the CI server will read this information, update the change log, increment the version number, and push a new release to the package manager. As a contributor this means that if your patch gets merged, it will be released.

What about Clojure?

I’m not aware of anyone doing this in the Clojure community¹ , but I believe it would be beneficial. There are a lot of small projects that would get contributions but the maintainers are not around to merge and release them. Automated releases would make the work of the existing maintainers easier and it would also make it simpler to onboard new maintainers.

I have implemented a proof-of-concept version of the Hypothesis process for cache-metrics, a small library of mine, but I haven’t yet dared to introduce it to any ”real” libraries. Many actively developed projects would need to change their ways of working as you couldn’t just merge or commit random things to master.

I hope this post acts a starting point for a discussion. What do you think?

Migrated to Hugo

After five years of using Hakyll to generate this site from a bunch of Markdown files, I finally migrated to Hugo. Hakyll is pretty cool, but using it makes only sense if you’re using Haskell for other stuff as well. I haven’t touched Haskell lately. Alas. Hugo has everything I need built-in and seems to work well enough.

I’ve tried to keep all the important URLs same or add redirects when that is not possible. Feed readers might do something weird with the updated feed, though. Sorry about that. If something is broken, please let me know.

Lead Developer London 2018

Last week, I attended The Lead Developer conference in London. It’s a conference about being a technical lead. The talks were a mix of general leadership advice (it’s all about feedback!), tech lead specifics (focus on the high-impact stuff in code reviews!), tech (ReasonML is cool!), and self-help (remember to exercise and meditate!).

I decided to attend the conference because I’ve ended up taking on some tech lead responsibilities and I’ve felt that I don’t know what I’m doing. Spending two days listening to talks about tech leadership seemed like a good idea.

The talks repeated the fundamentals: getting and giving good feedback is a key activity, you need to have empathy, and you need to be able to articulate why you’re doing things in addition to how. The hard part, of course, is putting these ideas in action.

The most interesting talks

I have this taxonomy of conference talks that I like. It subjective since it depends on what you already know. Here it is anyway:

1. Clarifying talks. These do not necessarily teach you new things, but they make you see the things you already know more clearly and connect them to other ideas.
2. Inspiring talks. These make you want to do things and do them well.
3. Toolbox talks. These talks give you actionable ideas to use in your work. Great if the ideas are new to you, potentially boring otherwise.
4. Tour talks. These talks walk you through a topic by covering a lot of ground with way too many details in way too little time. The audience might get confused, but I like that.
   

Here are my highlights from the conference in each of the categories. Unfortunately the videos haven’t been published yet.

Clarifying talks:

• Alex Hill’s talk on code review. She talked about how defensiveness can get in the way of effective code reviews and what to do to avoid it. See Alex’s slides and her blog post. My commandments for code review were inspired by similar ideas.
  
  

Inspiring talks:

• Tara Ojo’s talk on mentoring junior developers. I’ve heard so many stories about early-career people getting hired but then forgotten by the company. Without help and guidance, there’s a big chance that they won’t succeed and then they either leave or get fired. This is waste of everybody’s time. See Tara’s slides, she has good suggestions on what to do.
• Alicia Liu’s talk on how to navigate your job when you get promoted to a new management position and have no idea of what you’re doing.
  

Toolbox talks:

• Kevin Goldmiths’s talk on techniques for 1:1s, team meetings, etc. I haven’t got much experience with these, but his methods sounded good. See Kevin’s slides.

Tour talks:

• Jenny Duckett’s talk on how to build sustainable teams. There was way too much information for me to process in one go, but what stuck with me was that you and your team should make a habit of sharing information about your work frequently to prevent the silo-ing of knowledge. For example, actually write down why you decided to do something. See Jenny’s slides.

On the event

Usually the conferences I go to have been organized by people who are not professional event organizers. The Lead Developer conference is organized by an event organizing company and it showed in a good way: everything was smooth.

My only complaint is about the venue. The lobby was so noisy during the breaks that it was hard for me to hear what people were saying. This obviously makes having a conversation hard and so I didn’t get much of talking to people. Otherwise the Barbican Arts Centre was a pretty good venue. Even though there were something like 1100 attendees, it didn’t feel crowded at all.

Some nice touches that would be cool to see at other conferences:

• Live captioning. All the talks were captioned live: next to the big screen, there were smaller screens where the stenographer’s text was projected. Obviously this helps the people with hearing difficulties, but it’s great for everybody. If you lose the context for a second or if the speaker uses weird words, you can look at the captioning and get back on track.
• Speaker office hours. Instead of a Q&A session after each talk, there was a room where you could meet the speakers during the break after their talks and ask them questions. The one-on-one conversations were interesting and you didn’t have endure any “this is more of a comment than question” takes.
• They played kick-ass music when the speakers entered the stage. Really gave me feeling that we’re now going to hear from an amazing person. I assume it made the speakers feel cool, too.
• They had a quieter chill-out area. There were guided mindfulness sessions, and while I’m not into guided meditation myself, the sessions ensured a peaceful atmosphere.

In general, I’d recommend the conference if you’re the kind of person who likes conferences, you’re interested in this topic, and your employer foots the bill.