Custom Code Deployment Methodologies

Purposeful consistency

John T. Mills
John T. Mills
Custom Code Deployment Methodologies

Servers will always need custom code to support purpose-specific customization as well as standardization. They need simple services and checks installed and automation configured to enable them. How this task is achieved can vary by the system owner's preferences or by the requirements of the actions. My thoughts, as follows, are how to put the priority on the latter rather than the former.

Requirements

Several questions should be asked as custom code is deployed to an OS. Before deployment of any method the service needs to be defined in the following ways:

  • Execution Type
    • Scheduled, periodic
    • Unscheduled, ad-hoc
  • Privilege
    • Privileged
    • Unprivileged
  • Compartmentalization
    • User
    • File system
  • Audit
    • Execution, history
    • Inventory

Approaches

Unstructured

The most common approach, and least recommended, is unstructured. Code is deployed:

  • Execution Type
    • Ad-hoc
  • Privilege
    • Privileged
  • Compartmentalization
    • Root
    • Placed in a home or temporary directory
  • Audit
    • Unlogged
    • No details recorded of the code

Before CVS usage became popular, custom code was rarely stored anywhere beyond where it was developed and deployed. An unstructured deployment was a standard approach. It could be managed effectively by a small group with some institutional knowledge. In this case, system backups generally replace the CVS requirement.

Automated

Another popular approach is automation. This can be a compelling approach because it's a large improvement over an unstructured deployment. Automation by itself has some limitations.

  • Execution Type
    • Periodic or ad-hoc execution
  • Privilege
    • automation server access method, possible escalation
  • Compartmentalization
    • User possibly, after initial authentication
    • Directories, possibly derived from the automation tool installation base
  • Audit
    • Automation tool logging
    • CVS, and possibly execution code logging on endpoints

Automation is a powerful methodology, but basic automation is over 20 years old on most OS platforms. There's a more complete approach using a larger framework.

Bundled Automation

Some automation tools have an integrated CVS (or externally connected). With this type of tool a small library can be maintained as functions to be called or nested from a remote automation console. This goes beyond basic automation, as, simple automation is very similar to remote job execution. Bundled automation has a benefit of allowing the assembly of a function library.

  • Execution Type
    • Periodic or ad-hoc execution
  • Privilege
    • automation server access method, possible escalation
  • Compartmentalization
    • User possibly, after initial authentication
    • Directories, possibly derived from the automation tool installation base
  • Audit
    • Automation tool logging
    • CVS, and possibly execution code logging on endpoints

This is a really good option. One-time projects fall into this bucket as do standard changes. It serves most purposes, but it does hide some important bits from anyone trying to troubleshoot from the OS side. Moreover, OS experts may have to grow into automation experts at the expense of OS proficiency. The key to this approach is administration access to the automation engine. If automation tool access is limited, then another approach may be better.

OS Packaged Automation

The last method is perhaps the oldest form of automation and least used. It provides the best of all the options when leveraged with an automation system. If a local scheduler is leveraged, execution continues even in a fenced mode.

  • Execution Type
    • Periodic or ad-hoc execution
  • Privilege
    • local/service access, possible escalation
  • Compartmentalization
    • Root or User
    • Directories or file system
  • Audit
    • Local logging, remote forwarding, automation tool
    • OS package database, CVS, patching service

The most rigorous option is packaged automation. This is not to be confused with a release driven approach to OS management, using automation. Instead of using complex system routines in the function library of the automation tool, simple routines are used to manage package presence and service configurations. The complexity is moved to a library of packages. This approach reduces deployment speed but increases transparency. This is a good option in environments where rigor and audit are the primary priorities. Packaging can be completed in the same timeliness as automation bundles, but OS packages fall under strict release management procedures and timelines in most cases.