Article | Remember: Sandbox & Release Often

Remember: Sandbox & Release Often

By NIAID (Swine Flu Strain Virus Particles) CC via Wikimedia Commons

The latest petra ramsomware virus (which is currently doing a global sweep disabling unpatched windows systems) is a good reminder of the anti-patterns that are prevalent within IT across many large enterprises whom take a risk adverse approach to software development and deployment. It is a result of many bad smells including a slow release cycle, and lack of sandboxing separating the applications from underlying technologies. This cascades into the infrastructure team creating dependency hell and a lack of timely security updates.

Don’t build for a System Platform.

Your software should not be tied to the platform, use of (even) java, ruby, or erlang separates you from the software system and the physical platform that sits on — meaning OS version and type can vary without affecting your software runtime.

Never build for a versioned browser.

Building for a browser version is a ticking time bomb and will increase and eventually prevent you from applying system level updates. If you build for Chrome, this auto-updates so version patching at the browser level becomes a thing of the past.

Always practice Continuous Deployment.

Don’t be scared of deployments. Deploy small changes often. Lots of small deploys will keep your systems alive, iron out the small errors that clog up your exception reporting systems and allow for a much more active, alive, and finger on the pulse approach to the running of your software. Holding back on deploys from perceived risks is a no-win scenario and spirals into very infrequent large deploys that have risk all over them and are expensive to conduct.

Integration Test Suite.

Always build and maintain an integrated test suite that is integrated into the development and deployment process. This allows you to trust your software so that small releases won’t cause you unnecessary stress — and is an enabler of continuous deployment.

Any software that does not have an active and full test suite is basically legacy and should be in the pipeline for replacement.

The Future is now

I am particularly excited by serverless technology. This has the potential to isolate the runtime of the app from the server, so serverside security updates become greatly simplified. Watch this space.

Message sent
Message could not be sent