We've upgraded our Fabric deployment scripts so that we can now see all of
the commits that will be pushed as part of the deployment.
As we mature as a company and a development team, our use of Fabric to script
basic tasks is also maturing. Our latest addition is to incorporate the git
changelog into the deployment . . .
P introspection with logging_tree
Have you ever wondered where all your logging information is coming from (or even where it's going to, or possibly why it's all duplicated)? If so, then logging_tree is your saviour.
I came across the logging_tree library recently as I was following a specific issue in the
urllib3 library, regarding the proliferation of INFO . . .
A run of pickling problems with our tests has required us to delve into the rq and django-rq source code. If you run rq in synchronous mode, queued functions are run directly by the
enqueue method, but redis is still used to store 'job' information.
We use the redis -> rq -> django-rq chain to run all our async . . .
Heroku's deployment model has always had a single point of frustration - the requirement to take the site offline, if only for a couple of minutes. In certain circumstances this is solved by the 'preboot' labs feature.
I love Heroku's simple git deployment model, and having lived with it for almost a year, I can't . . .
Efficient workflow and task management using Trello
We've recently taken on a third developer (well, second developer, but I'm also counting myself), and our ad hoc workflow took a battering. So we upgraded.
As I have blogged previously, we use gitflow as our workflow, and as I may have mentioned, we use Trello to track what we're actually developing. When it was just . . .
Last week I finally managed to provoke our tech lead into using the 'F-word' in conversation. The trigger for this outburst was none other than HTTP status codes, and my desire to invent a new one. This was clearly beyond the pail.
I have since retreated from my original stance (a custom status code), but have committed a . . .
This is the opening doc that we share with new team members, outlining what
we expect of them in terms of coding standards and git etiquette. It's not
a lot more than 'be a good citizen', but thought some others may find it
First off, welcome aboard. This isn't a public project [ clearly this . . .