From 548fdcaeecfadcde234f83184cda4499f066abb3 Mon Sep 17 00:00:00 2001 From: Olof-Joachim Frahm Date: Thu, 9 Apr 2015 13:18:12 +0200 Subject: [PATCH] Add post about configuration management. --- reifying.post | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 reifying.post diff --git a/reifying.post b/reifying.post new file mode 100644 index 0000000..138309b --- /dev/null +++ b/reifying.post @@ -0,0 +1,36 @@ +;;;;; +title: Reifying Hidden Code +date: 2015-04-09 13:17:46 +format: md +;;;;; + +The title sounds a bit too majestic too be true. However the though just +occured to me, that much of what I've been doing over the last months often +involved taking "dev ops" code, e.g. configuration code that lives in the +deployment scripts, and putting it into a reusable format, i.e. an actual +(Python) module. + +That usually happens because what was once a depencency for an application (or +service if you like), is now needed to be accessible from (Python) code for +testing purposes, or because the setup routine isn't actually just setup any +more, but happens more regularly as part of the application cycle. + +Of course doing this has some major downsides, as the way scripts are written, +using a specific library to access remote hosts, without much error handling, +is fundamentally different from how a application code works, that is usually +with a more powerful database interface, without any shell scripting underlying +the commands (which will instead be replaced by "native" file manipulation +commands) and with more proper data structures. + +That leaves me with some real annoying busy work just to transform code from +one way of writing it to another. Maybe the thing to take away here is that +configuration code isn't and application code will sooner or later become +library code as well -- aka. build everything as reusable modules. This of +course means that using certain configuration (dev ops) frameworks is +prohibited, as they work from the outside in, e.g. by providing a wrapper +application (for Fabric that would be `fab`) that invokes "tasks" written in a +certain way. + +Properly done, that would mean that configuration code would be a wrapper so +thin that the actual code could still be reused from application code and +different projects later on. -- 1.7.10.4