One does not simply develop software, take it live, and finish the project. In enterprise applications, the deployment is often just the beginning of the “Software Lifecycle” – the process by which the software is maintained and updated over the course of 10 to 20 years. The better the design and support of the software, the longer it will last and provide benefit to the client.
In order to ensure that web application maintenance is seamless throughout the software lifecycle, it is important to set up at least three project environments: Development, Test, and Production. The development site is generally only used by the programmers, and can change or break on a daily basis. No important data should be stored on the development site, as this could be deleted and restored during the course of any system updates. If a certain set of testing data is required, the insert statements that generate that data should be saved in an external file, so that the data can be reloaded in case it is deleted.
Once a stable development build is completed, the site should be moved to “Test”. The test, or acceptance testing site, should be accessible by the client, and an area where the client can validate system functionality. The Test site is also an opportune area for testing production data. Once the client approves the updates and gives the go-ahead to take the system live, the production data can be copied back to test for verification that everything will work well, before the production system is overwritten. This will also speed up the move to production, and reduce live system downtime.
Out of the web development frameworks, ASP.NET offers the most comprehensive deployment functionality through Visual Studio – its integrated development environment. By specifying deployment targets and using XSLT “Transform” files, the database and relevant parameters can be customized per environment. In addition, Visual Studio offers a one-click publish with code compilation.
The other web frameworks, including PHP, Node.js, Rails, and Django, all require custom scripting to build a one-click deployment. Out of these four, PHP is the easiest to work with, given its lack of state, and that the server does not need to be restarted on publish. Since Node, Rails, and Django all run a custom web server, some deployments on those platforms may require restarting the server, while others might simply need a file replacement. Node, Rails, and Django are also often paired with a separate content server for the images and static content files, so the state of that service will need to be managed as well.
Regardless of the configuration, it’s important to create scripts for a one-click deployment procedure. This not only ensures documentation of the necessary steps to take software live; it also speeds up the publish process and helps to reduce system downtime. Join us in the next article in this series, where we review web framework support for a robust database backend.
Written by Andrew Palczewski
About the Author
Andrew Palczewski is CEO of apHarmony, a Chicago software development company. He holds a Master's degree in Computer Engineering from the University of Illinois at Urbana-Champaign and has over ten years' experience in managing development of software projects.
Google+
