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. The difference between configuration and business logic would then be more of a distinction between where code is used, not how and which framework it was written against.
