Improving the developer experience

I believe we need to improve the developer experience/workflow for people contributing to dCA projects. From the creation of pull requests the bring changes through to the release of new versions, there are some simple changes that can make life easier for developers.

I’ve made a start on bringing these changes to the dCA and I think we should define a template approach to these tools so that we can bring a consistent experience to each project. This should in turn make it easier for people to contribute.

Pre-commit hooks in git are the first place where we can improve. For anybody unfamiliar with these hooks;

Git hook scripts are useful for identifying simple issues before submission to code review.

Essentially we can run scripts prior to git performing a commit. Scripts might run linters like flake8, or isort which form part of the github actions for most, if not all, of our projects. By running these tools through pre-commit hooks, problems will be resolved prior to a commit, so the linter github action should never fail. Also our python code itself can be modified by these scripts with the likes of pyupgrade and django-upgrade which can be ran to target specific versions of python and django to ensure that code utilises the features of them. For example, pyupgrade targeting python>=3.6 will convert string formatting to use f strings where it can. What I’d call a basic setup for these hooks can be seen on this PR

After PRs are merged and a release is required we then need a release process that makes it easy for us to get new versions out. So this starts with the preparation of a release, setting the new version number, updating the change log, etc.

bump2version is a tool which will update version numbers and update the changelog from a single command. It can also automatically commit and tag from that same command. The configuration for this can likely be very simple, using auto commit but not auto tag, and the replacement features for the package __init__.py where the version number will be and the changelog where the new versio needs to define what has changed. This can be seen in this PR. A caveat to this is that in the change log, the “unreleased” section needs to be maintained as PRs merge so that the automation prevents manual tasks during a release.

The final tool is for the release to pypi itself. This comes in the form of github actions and that should mean that it’s easier for us to get new versions out. My approach with this is that when there is a push to master (a PR merge, for example) an action will run which builds the package and uploads it to test.pypi.org to ensure that master is in a state where it can be built & released. You can see that action here. Once a release is required we then have another action which will trigger on the publishing of a new release on github. You can see this action here. Releases are something we likely haven’t done a lot of using github so far, but recently I released django-sekizai, django-classy-tags and djangocms-admin-style using this workflow. You can see the django-sekizai releases here.

I welcome any suggestions on further improvements.

If you’re curious about ways to improve your developer experience, I found this book really useful.

1 Like