Intelligent Environment’s software is changing. We’re transforming Interact’s core into an Engagement Platform based on microservices, and our UX Evolution project is delivering next-generation design that’s fresh, tailored and human.
It‘s not just the shiny stuff that’s moving on though, behind the scenes a quieter but no less important retooling is taking place too.
In the past few years new ways of thinking about how digital financial software should work and scale has led to new ways of thinking about how it’s developed, built and deployed:
- Agile development has driven trends for cross-functional teams and smaller, more frequent, less disruptive changes.
- Containers and Virtual Machines have got people thinking about whole environments rather than just software.
- Tools like Puppet and Chef that promise to “turn infrastructure into code” have made provisioning a predictable, scriptable exercise.
The umbrella term for all this innovation is DevOps, a practice that’s using automation to overcome the traditional difficulties of software deployment and making it something that’s predictable, reliable, frequent and fast.
At Intelligent Environments our typical release cycle is a more-than-respectable 2 to 3 months but we’ve got plans to go much, much faster.
A unique environment
Unlike most software houses Intelligent Environments doesn’t produce a one-size-fits-all product. Each of our customers has their own unique combination of environment, priorities and users. Our development process is designed to be flexible enough to deliver bespoke financial services solutions for each customer based on a common core.
To do this our products pass through two development phases. Core features are developed by Product Delivery teams and their work is made available to dedicated Client Delivery teams paired with each customer.
Client Delivery teams work side-by-side with a single customer to produce something that’s unique to them but still recognisable as Interact.
Because of this our software has to operate on all manner of machines and environments. Even before our software leaves the hands of Product Delivery it will have run in development, integration, release and demonstration environments.
From there it moves onto the many and diverse varieties of infrastructure operated by the Client Delivery teams and their partners before it’s finally deployed into customers’ live environments.
Continuously Available Development
The challenge of deploying working digital financial software to myriad environments hosting different versions of code at different stages of development, rapidly and in a totally repeatable and predictable fashion can only be achieved with automation – specifically, automated provisioning and automated deployment.
Our unique development challenges mean that we can’t just roll out an off-the-shelf delivery mechanism and it prevents us from practicing Continuous Delivery (CD). What our requirements demand is something like CD that’s driven by a ‘pull’ from the periphery rather than a ‘push’ from the centre.
What we’ve come up with is our own take on deployment, something we’re calling Continuously Available Development or CAD for short (we may have to work on the abbreviation though – Computer Aided Design has a 50-year head start on us there!)
In a nutshell it standardises how we get something on to a system.
It relies on a combination of tried-and-trusted products working together, fronted by dashboards built in-house. We’re using BitBucket for code, Team City for continuous integration and Artifactory as our binary repository. Our software environments run inside Amazon Web Services instances or VirtualBox virtual machines and everything is provisioned by Chef.
CAD gives us the ability to spin-up provisioned environments on demand: want to pull new features into a Client Delivery build? Done. Want to run a specific version of Interact? No problem. Need a new environment with n nodes and t tiers to test out feature X? It can do that too.
CAD even turns the headache of all those myriad environments, scenarios, features and versions we work with into an advantage. By the time our software is deployed to a live server not only will the software itself have been tested over and over but so too will the deployment process that got it there. When you press “live” you’ll be triggering a process that’s already worked over and over again.
That sort of predictability should reduce the amount of hair pulling that happens during deployment and that makes it easier to do it often, turning deployment into something like publishing. Instead of bundling changes together and doing big releases every few months we can untangle the individual features and release them to every developer that wants them, every staging environment, every demo and every customer the second they’re ready.
