CodeData Split: New OMC Design Pattern
Alex Honor /
One everyday source of confusion seen during the dev to ops handoff is the necessary modification of files during the installation and setup during deployment. Typically, there is one or more modifications to configuration files that enable the software to work in the context of the target environment. The process can be greatly improved if these files were split away from the executable software code itself. I describe this best practice as the CodeData Split:
Separate executable software files from environment specific deployment ones, identifying files that change during installation or operation, thereby facilitating cleaner upgrade process, and the ability to manage deployments independently and separate from each other.
The concept of splitting code from data in applications is nothing new and examples can be found ranging from OS filesystem structure and application servers. The pattern emerged in those places because the operation of the software was a clear requirement so this led to the data files (both configuration and variable data files) to have their own places. This best practice should be followed generally for any application. Doing so will avoid problems like the Service Monolith
