TravisCI docs: https://docs.travis-ci.com/user/deployment/script/
Might not work since cherry_picker now uses pyproject.toml instead of setup.py

CircleCI example https://circleci.com/blog/continuously-deploying-python-packages-to-pypi-with-circleci/

My own idea is to write a bot that does flit publish.

I can do it. If needed, I'll send a PR to travis-ci/dpl for the existing pypi provider (I wrote Pages provider, so I'm familiar with the tool), but it's likely that it won't be necessary.

Another thing to consider would be the deployment flow trigger. Normally, I would do deploy for every tag pushed and even use that version-tag as a version of current distribution (see setuptools_scm).
But in this repo there's two distributions (blurb and cherry-picker), which have different versions, so we need some hack to distinguish them.
I suggest something like prefixing cherry-picker-vx.x.x or blurb-vy.y.y must be enough. If you don't wont to rely on git tags in dist you'll still have to edit and commit version in source and then tag it (as opposed to just tagging and pushing a commit).

Regarding bot, I've got some ideas and having ongoing investigation of how GitHub Deployments APIs work along with GitHub Apps (login as a bot) + OAuth there. I don't have any public demo yet, but the plan is to make some UI with a button, which would trigger a deployment event and then the event listener part of app will react on such events and do whatever needed. I'm also considering another scenario where CIs will send such events. If I understand correctly, one may even add a condition into such trigger in API to wait for all CIs to complete, which is going to be very useful for aio-libs (where I originally intended to apply this), because in case of several CIs building OS-specific wheels asynchronously the wheels appear in PYPI during 8-hour interval, which seems to be very confusing to users. So this bot could be a nice "synchronization point" for such processes.

But it all is just a theory for now. I'll start with what I know best: built-in deployment provider.

@Mariatta Please let me know if you prefer somewhat different flow. And perhaps we could move the discussion to #262, shall we?