22

Operational Excellence Week: Release Engineering

Video pending upload

But.. it works on my machine
There isn't an organisation in the world free of this phrase. When developing complex software, there will always be differences in behaviours between local environment execution (like a laptop used for development) and a production environment - deployed on-premises or in The Cloud. While fingers are usually pointed at dependency management or configuration - every variant impacts it. The author had a similar scenario, having spent months debugging a script that just wouldn't work in production - only to later discover it was due to en_US vs en_GB locales causing different ordering in a sorted list.

Short of shipping a laptop to a datacenter to form part of the production environment - there are many other ways this problem can be addressed.

Don't develop locally at all

Controversially, there is a growing trend to stop local development. While historically the cost considerations of this action would be too great - with the reduced cost of compartmentalisation of resource through Cloud, VMs, or containers, the cost of implementation is dropping through the floor. Furthermore, thanks to high bandwidth and low latency networks becoming ever more available - this has become even more seamless.

To achieve this, we need a few building blocks in place:

  • Subscription / Account Management - when access to Cloud is seamless, adoption is inevitable. Patterns such as the Subscription Vending Machine allow fast access to Cloud subscriptions - while still maintaining cost and compliance controls through policies.
  • Dependency Automation - because the moment a dependency is installed manually, variants such as versions or upstream sources may be introduced. Through consistent dependency management and minimal manual dependency resolution, we reduce anything that may add friction to deployment
  • Deployment Automation - by making this as straight forwards as possible, built into a developer IDE such as Visual Studio Code , we can mimic the local development experience and reduce the adoption barriers for developers. Utilising the exact same patterns as production also reduces our costs and improves efficiency.

While Release Engineering is never a straight forwards task - by removing the entire problem statement of "it works locally" - we can improve agility and remove any barrier to our Cloud Ready journey.