Development, Automation, and Saving Time
(Note to the reader: this post has actually been a draft for a number of years.)
I’m a developer. I write code. Also, I’m just one guy with limited resources, so I can’t be spending a bunch of time testing my code in a bunch of different environments, or making sure that every single little change I make doesn’t have some unknown catastrophic ripple effect.
So I automate my life. I take advantage of freely-available tools. As much as possible.
How, you ask?
Self-Hosting Isn’t Worth It (sometimes).
First off, I don’t bother trying to do everything myself. I used to host my own code repository (a really, REALLY long time ago), and this took excess time to:
- work with (use)
- keep updated
- handle security crap like SSL (you know, changing the website to https://….)
So I use GitHub. I’ve used SourceForge.net in the past, and it was alright for my first everyone-can-see-it code repository, but GitHub just feels nicer to work with. Going from SVN to Git was a hell of a learning curve, but totally worth it (yes, SourceForge now supports Git, but not when I switched). All my code gets out into the world, others can see it, and I get a tiny bit of exposure.
That said: self-hosting is a lot cheaper, if you’re willing to sacrifice time for money (like if you’re a poor nerd 🤓).
Continuous Integration is Very Important.
Unit testing helps avoid introducing bugs that have a nasty ripple effect. I’m not that great at getting massive code coverage with it, but I’m getting better at it.
The other thing is that, really, I can only directly (read: easily) test with the version of PHP available to me. Which is usually the newest version. And my server, or the servers that would potentially use my code, don’t necessarily have that new of a version… so I need to have something test against those old versions. That’s where Travis-CI comes into play.
So I setup the GitHub repository to work with Travis-CI. Every time I push something to GitHub, Travis-CI gets notified. They spin up a fresh new virtual server for each version of PHP that I declared my code to be compatible with. And they run all my tests in that environment. Oh, and they email me the results. WIN.
Semantic Versioning is Important.
Putting readable, easy-to-understand version numbers in the code makes life easier. Well, usually, except when I fall into “version hell,” where this project requires that project which requires another project, and none of them can decide on a version of a related project that they both like. Yuck.
Anyway, I’ll probably write more on this later. Maybe. If you’re lucky. (And I have time… Which is basically never.)