Category : Web Development

Development, General, PHP, Web Development
0

Config Migration

TLDR; I made a thing for migrating my configuration files, I like it, and it’s available for use here: https://github.com/AndyM84/config-migration

As the technology world settles into the ‘DevOps’ era and begins passing it out to other areas (looking at you, marketing automation), I figured I’d share one of my deployment “pet peeves” and solutions.  Further embracing my love of disclaimers, keep in mind that this is my own cockamamie solution, and I’m just as likely to be wrong as right.

The Problem

It seems there’s a bit of a gap in many companies’s deployment systems.  Numerous jobs I’ve held in recent years have worked hard to put various types of automation in place, but for whatever reason there wasn’t a lot of thought lent to automating configuration files during deployment.

In almost every case where this was possibly a concern, it was either expected that the system would gracefully fail when new configuration values were missing, or it would be left up to some poor release engineer to figure out which configuration property was missing and thus causing the newest in a long series of catastrophic upgrade failures.

Either way, expensive blocks of time were wasted or only protected because of extremely dedicated and entrenched individuals.  Is this a huge time-sink for release engineers?  Obviously that depends, but at the least this is hardly a ‘DevOps-y’ approach to things…

My Solution

With this in mind, I did what I do best/most-often, which is to create a solution before searching for something else that did the job.  My simplistic solution was two-fold:

  1. Restrict my settings files to be non-nested JSON strings
  2. Build a simplistic migration instruction set that allowed me to add, change, rename, and remove settings properties

#1 was mostly influenced by the infamous web.config files used by IIS/ASP.NET.  I love IIS and ASP.NET, but working through web.config files always felt to me like trying to navigate that corridor of horrors from Indiana Jones and the Last Crusade.

That’s gonna be a whole lotta nope from me…

#2 is equal parts ego (thinking that I know better than everyone before me) and a strong desire to mimic the same sort of process used with database migration utilities, such as RoundhousE.

The result of this was a system based around files, named <OLDVERSION>-<NEWVERSION>.cfg (eg, ‘3-4.cfg’) that contained instructions similar to this:

coreVersion[str] + 0.1.0
siteName = A Site
database_host > dbHost
emailFrom -

This file would do the following things, in order:

  1. Add a new setting, coreVersion, of type string with the value ‘0.1.0’
  2. Change the value of the siteName setting to be ‘A Site’
  3. Rename the database_host setting to be called dbHost
  4. Remove the emailFrom setting
  5. Update the configVersion setting to now be the integer 4 (was 3)

I’d already been in the habit of using a script to manage my configuration files (keeps me from having to worry about the format of the file itself), so all I had to do was insert this migration system onto the beginning of that script.  This means I can now run my typical ‘version’ update call and feel confident that any new fields added to my setup script will be present:

php ./scripts/configure.php --non-interactive --PcoreVersion=0.1.0.25

In Conclusion

After all of this jibber-jabber, this is ultimately a simple problem to which I’ve given a simple solution.  I’m sure there are other (better?) ways to handle this sort of thing, but until I find them I’ll be using this to alleviate at least one other thing in my CI/CD pipeline.

Just to make sure I’m remembering to share, I’ve published a PHP version of this system on my GitHub for your amusement.  I’ll probably throw this (or at least some version of it) into one of my many-splendoured frameworks at some point, but for now I think I’ll move on and get back to some actual work.  Enjoy!

https://github.com/AndyM84/config-migration

– Andy

Read More
Development, General, JavaScript, PHP, Self, Web Development, Weekend Projects
1

Weekend Projects Gone Awry, Part 1

Lately I’ve been spending a lot of time at home, which has produced an odd side effect.  It seems the more time I am left alone, the more I get stuck on ideas without real merit.  Generally speaking, these are passing thoughts at best, but sometimes one takes root and seems dedicated to obstructing real productive thought.

In past years, I’ve simply bided my time until the thought eventually passed.  The more recent thoughts, however, don’t seem to be following the pattern.  Whether because of changes in my personal life, or the ongoing process of maturing, I find myself having to invent new methods for clearing my mind.  And so we find ourselves here, dear reader, where I will attempt to quickly bring these concepts to life and subject you to the process.

 

The Idea: SlimSocial

At heart I am most comfortable playing the role of an introvert.  As such, the world of social networking is irksome to say the least.  Don’t get me wrong, I have met many great friends thanks to the internet, but I also think they talk too much at times.  With that in mind, I’d like to introduce you to “SlimSocial,” my solution to social-overload on the internet.

 

Executing

Instead of allowing everyone to talk so much, I wanted to create a simple network that limited the number of posts someone could make per day.  Initially, I’d envisioned limiting everyone to one post per day, and most of my prototype work has been done with that in mind.  If I were to put more work into the system, it would be more appropriate to generate a system on top of the “likes” and “dislikes” a person accumulates.

Speaking of likes/dislikes, since I’m robbing people of the ability to flood the network with their idle musings, I certainly can’t take away their ability to show support or disdain for their fellow network members.  Still, I couldn’t quite re-use the terminology of sites like Facebook, Reddit, etc.  I spent a while racking my brain on what to call this feature, and eventually got a helping hand from Jordan.  He took the “Slim” in the title a bit more anatomically, and suggested the system use weight loss or gain to represent likes and dislikes, respectively.  Imagining the confusion this could cause, I quickly jumped on the idea and the chance to further solidify the network’s uselessness.

 

Tech Notes

There aren’t really any interesting tech notes for this project, except to say that there aren’t any interesting tech notes.  What I mean by that is that I decided to forego utilizing any frameworks outside of jQuery and Boostrap on the UI.  This was the first PHP project I’ve done in years without my framework (N2F) save for a game to keep tallies of annoying phrases on phone calls I did for a friend over the course of 2 hours.  The whole experience was…enlightening.  I can now say I know what parts of my framework are the crucial ones that really do save me lots of work.  Beyond that, I might say I got to practice a little more with build/release automation in TeamCity, but that was less a goal for the project than it was a result of my server outage.

 

Conclusion & Reveal

I had hoped to make the prototype for this project over the course of a weekend.  The mockup took about an hour after I found a template, but the remainder of the work was broken up due to said server outage, the holidays, and of course my day job.  I’d estimate I spent 4 full days of work (32 hours) on the project to get it to where it sits today.  The prototype is essentially complete, and though there is obviously more work to do, it is time to move on…or so I hope.

 

http://slimsocial.zibings.com/

 

– Andy

Read More