July was a more encouraging month, at least in terms of user growth. In July I had a 19.3% growth in users over June, however I made $3 less! Oh well, I keep saying I care more about user growth than income growth. Users tends to be more stable, which means I expect income to catch up at some point.

In terms of progress I made a major change under the hood. I had previously been using a two stage deployment. I had two different work environments, a development environment were I could work on changes and a production environment that hosted the live website. To reduce user bandwidth, I’d compress files while moving them from development to production. This worked fine up until now as I could always fine a time of low to no user activity.
As long as I followed my own invariants, the compression worked seamlessly. When I broke them, I could quickly undo the compression before anyone noticed and avoid much disruption. Downtime was no more than minutes at most, and there were always some minutes a day (usually in the middle of the night) where it could be risked.

Datayze has grown to the point where that is no longer the case. Some apps don’t really have down time anymore. Less trafficked times of the day are no longer no traffic times. In some cases I’d wait days before having an opportunity to push a change. It’s good news for datayze, but means I need to split up and test the compress step independently of the push to production.

Now I have three independent silos, one for development, one to test the compression, and one for deployment. Technically I have a fourth “sandbox” silo for crazy, half formed ideas, but there’s no automatic method for pushing from there to development. I keep the sandbox completely separate from development so I don’t accidentally deploy something very not ready for prime time. I don’t want to get a reputation for broken code and wonky, misbehaving apps!

The change should help increase productivity. Now I have much more flexibility when I deploy.