Add post about configuration management.
authorOlof-Joachim Frahm <olof@macrolet.net>
Thu, 9 Apr 2015 11:18:12 +0000 (13:18 +0200)
committerOlof-Joachim Frahm <olof@macrolet.net>
Thu, 9 Apr 2015 11:18:12 +0000 (13:18 +0200)
reifying.post [new file with mode: 0644]

diff --git a/reifying.post b/reifying.post
new file mode 100644 (file)
index 0000000..138309b
--- /dev/null
@@ -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.