You like to see things done efficiently. It’s true of pretty much everyone, a shared professional ambition whatever the role. It’s perhaps doubly true for software developers, for whom a penchant for efficiency comes with the territory, whether it’s the architecture of the software they build or the development methods they employ.
Forward-planning is a big part of efficiency – our own teams have often been in situations where a client wants the solutions we’ve created for them to support a whole new arm of their business, and it’s in these instances that software developed with one eye firmly on the horizon really shows its worth.
As part of this future-proofing process, our teams have recently been working on improving what happens once software is ready to roll: deployment. We’ve started using automated deployment tools and methods to simplify the whole process and allow for quicker build updates, which in turn benefits that all-important capability for software growth. When you’re working with clients who rely on your software for their business processes, and are on tight time budgets themselves, speed is of the essence.
What’s software deployment, and why does it matter?
If you’re not familiar with software deployment, it’s basically getting your software ‘into the wild’ and seeing if it acts as expected in its intended environment, making sure the software runs properly and performs optimally on the client’s hardware and software setup. A client may have just one server that their new, bespoke software has to run on. More typically they have several, which work with each other.
Deployment involves several stages, including identifying the correct areas of the client’s environment that different elements of the software need to reside on and going through configuration procedures to ensure that the software is interacting correctly with that environment and its sibling components.
It can be a lengthy process. I asked one of our senior software developers for an estimate on the time it took for the initial deployment on one particular large project, and the reply was that it could take around 30 minutes. It’s also repetitive, requiring the developer to repeat the whole process each time a re-deployment is needed, such as following a feature addition or bugfix.
No matter how skilled your developers, the margin for human error essentially increases with each subsequent deployment; the more times it needs to be done, the more chance there is that something will go wrong. Additionally, deployment can be expensive in terms of developer time budget. It generally requires extensive knowledge of how the software being deployed works and how it is expected to interact with the target environment.
Automated deployment – making it all bit simpler
Automated deployment helps resolve, or at least mitigate, a lot of these issues. As the name suggests, it allows a developer to set up the deployment process to be run automatically at the click of a button every time a new deployment is needed. This means the margin for human error is not increased each time; if the original deployment is right, subsequent deployments will run to the same method.
In a multi-server environment, the developer can install a deployment ‘pipeline’ on each server, and then use an automated development software suite to deploy across these pipelines to the relevant servers. This makes setting up a deployment environment far simpler.
This quicker deployment in turn allows for more regular testing, increasing the level of feedback for developers to work with. In a world where data is king, automated deployment certainly gives developers more to work with.
Another benefit is that instead of manually carrying out each deployment, once the initial automation setup is complete, less experienced developers or non-developers can complete the task at the push of a button – all of which takes closer to half a minute than half an hour.
Putting it all together – deployment, integration and Agile
Automated deployment has the most impact as part of Continuous Integration practises, in which several developers working on different parts of a piece of software frequently combine their efforts into one, combined build, known as a ‘mainline’. These builds are then used for deployments to test environments, making the entire process resemble a conveyor belt.
Both practises are a natural complement for Agile development methodologies; both mean being able to react more quickly and identify issues sooner, freeing up developer time and resources. Agile is all about empowering developers, so any process that makes like simpler for developers is useful.
Happier developers build more efficient software – and that should mean they’re dealing with happier clients!