07-13, 11:35–12:05 (Europe/Dublin), The Auditorium
A huge source of friction in software is publishing new releases. Somebody has to manually review commits and write a change-log, add a version number, and publish to PyPI. We will cover a better way: an automated process in which new versions are automatically published by merging pull requests.
Empowering anyone to issue a new release by submitting a pull request? At first glance, it seems like an outlandish idea. Upon further inspection, however, the benefits become clear.
One of the biggest sources of friction in software development is packaging and publishing new releases. Somebody has to sift through the commits and write a change-log, tag it with a new version number, and publish the package to PyPI. And usually only one or two people have the access necessary for this last step.
The unfortunate result is an infrequent release cadence. Bug fixes and new features are sitting there in the main branch, but hardly anybody is benefiting from them because they aren’t in a shipped release yet.
Thankfully, there’s a better way: a continuous release process where new versions are auto-published via pull requests — without any manual monkeying.
In this environment, all pull requests must include a release file that describes the changes within. This file must also include whether the new version should be a major, minor, or patch release.
The continuous integration (CI) process looks for this file, and if one hasn’t been included, the tests will fail, and the pull request won’t be merged. Otherwise, a maintainer merges the pull request, and the CI process then uses the release file to put the description into the change-log, increment the version number, commit, tag, build, and publish the new release to PyPI.
So with almost no human input, every code contribution results in a new release in a matter of minutes. Every feature and bug-fix has its own release, without anyone having to remember to package and publish a new version. Plus, if a bug is found, it’s now much easier to trace it to a specific release version.
Perhaps the best part is that all contributors get to issue their own releases. What better way to welcome new contributors than to reward them with a dedicated release composed entirely of their own work?
Attendees of this talk will take home the following knowledge and skills:
- what kinds of problems are introduced by an infrequent release cadence
- how automated releases solve those problems and provide myriad ancillary benefits
- how to format and parse the release file
- how to use continuous integration (CI) systems to automate releases
- how to add deployment code so new versions are released when PRs are merged
- how to use AutoPub to facilitate this process
some
Expected audience expertise: Python –none
Abstract as a tweet –A huge source of friction in software is publishing new releases. Somebody has to review commits, write a change-log, add a version number, and publish to PyPI. There’s a better way: automatically publishing new packages merely by merging pull requests.
Justin Mayer is a serial entrepreneur, investor, and advocate for data portability and privacy. His latest project is Fortressa.com, which replaces expensive SaaS data silos with self-hosted open-source applications. He also maintains the Pelican static site generator as well as a number of other projects for Python, Django, and the Fish shell.
Justin speaks Japanese and Italian, graduated with honors from the University of California, Berkeley, and received his M.B.A. from the Wharton School of Business.
He writes about security and privacy at justinmayer.com and via @JMayer on Twitter.