March 9 another Sendcloud Engineering meetup took place. What follows is a summary of the virtual, lunchtime session with Nicole van Alphen, Product Lead at Sendcloud, and Tom de Bruijn, Software Developer at AppSignal, community organizer, and open source maintainer.
Shipping changes to business critical applications
The different teams at Sendcloud iterate very quickly, and on some days release up to 15 times an hour. But, where does releasing to the user fit in? What's an appropriate time to release to the user?
Customer feedback following a lot of small releases with changes to the frontend was one of frustration, confusion, some customers mentioned their workflow got disrupted. Users lack the time and focus to adopt new features instantly. While you're shipping new features, customers are trying to get their shipments fulfilled.
Collecting feedback during the development cycle is challenging. And, related, releasing new features with confidence can be a struggle.
Nicole: "We are not the user of the software we build. Keeping the user in mind is paramount. For instance, a picker in the warehouse can be a seasonal worker who doesn't have the time to be onboarded onto your platform. It needs to work for them right away."
Sendcloud releases software to different types of users in the following phases:
- Data management
- Internal users
- BETA community
- Our ~500 Beta users (or: power users) have been instrumental to help figure out whether we are working on the right things.
- All users
- New users
- Default
- Sunset
Sendcloud found low risk ways to release new features with 'try out' and 'rollback' banners. Nicole: "And when customers decide to switch back, we ask them to give feedback, but it's entirely optional."
With her colleague Caroline Overgoor (UX Manager at Sendcloud), Nicole wrote the blog post “Releasing the release strategy for SaaS software development teams” on this topic.
Automating opinions about Git
We can find a wide range of not-useful commits in the wild:
- "WIP"
- "Fix bug" (which bug?)
- "closes #123" (involves extra step to find the issue tracker)
... the above messages don't tell future you, or your colleagues an awful lot. Instead, commits should tell a story. Commits should have a subject and a message. Commits should be small, should explain what problem they're solving, why this is the right solution (and maybe what alternatives were considered). Bonus points for examples included, and links to resources.
Why? Commits are documentation. They're not THE documentation, but they are documentation and they are read during review, and later, during debugging.
Tom wrote down all his opinions about what makes a good commit, and gave a talk about it at a conference. The feedback was positive, everybody agreed they wanted to write better commits, but then no-one actually did, or does.
It seemed like the only path forward was to enforce good commits. When Tom couldn't find a tool to do the job for him he decided to write a linter himself, using Rust.
The formatting rules the linter he developed checks for:
- Actual changes (yes, you can push empty commits)
- Helpful branch names
- The maximum width of the commit's subject is 50 characters or less
- A commit message being there, and is max 72 characters
- Punctuation like an exclamation mark in the subject line (Tom is not a fan)
- Using the imperative mood for the subject
- Ticket numbers in subjects (those should go in the message instead)
-
fixupormergecommits, to then suggest rebasing before pushing or merging
Lintje (which means "little ribbon" in Dutch, "lint" in Dutch is a ribbon) is open source and able to be run in your CI, and Tom is accepting pull requests.
Watch the recording for the full length talks, and Q&A.
https://youtube.com/watch?v=Td3AOrEytxM
Our next meetup is planned for April 14. RSVP on meetup.com.
Top comments (0)