Deployment Test

/images/_ca2e3249-9c5d-4f14-91fb-4c0aaef4b9b4.jpeg

The plan is to deploy this site to a robust HTML-only server, which will keep costs down and security high, since there won’t be any programmatic interfaces on the site itself that can be hacked. My deployment engine of choice is simple: I’ll be using git push. But before I sign up for a hosting account and start pushing my brains out the door on an automated basis, I wanted to test that procedure on a smaller scale, here in the lab.

After reading up about git’s post-receive hooks, I decided that I would build a bare git repo on my lab server to push the site files to, and then set up a hook on that repo to make git copy the files to the web server’s html folder as part of receiving a push. After 10 minutes of typing and configuring, I ran a clean test and was able to view the site from the server. The system is coming together.


Read More


/images/_2ef531ec-bc45-46fe-841b-6864301fa06c.jpeg

Cutting The Monster Into Pieces

Now that I’ve identified a useable hosting candidate, my final test of their service will be to roll out a full implementation of the websmith deployment scheme. But in contemplating how I’m going to do that, I’ve realized that I may not have broken the project into distinct repos properly. So I’m going to figure it out by explaining it to the rubber duck. (Meaning you. :-)

/images/_53a3cde2-8eec-418a-957f-2a8bfade78c4.jpeg

Gitified

The first sign in my workflow that things are starting to come together on a project is when I start getting nervous that the next change I make will break it. After all, it can’t really be thought of as “coming together” if there’s nothing to break yet, right?