If you’ve ever tried moving your website from one server to another then you’ll know that this isn’t a job to be undertaken lightly.
This is especially true if your application is custom built, even more so if it has been sitting on the same server for some time and has had many changes applied to it. It’s likely that it has become embedded on that machine, dependant on the server being set-up in a particular way.
This is less of a problem when the server set-up and any customisations are documented, but what if it’s not? A simple re-upload to new hardware is likely to break and you’ll end up debugging the problems on a live machine; not a good situation to be in.
Even if there is documentation on how the application is to be set-up, it’s still likely that you’re going to run into problems. Documentation is never perfect, there Is always something that may have been missed.
If you decide to work with us at Siftware to maintain and support your application then one of the first things we’re going to suggest is that you get your application’s architecture upgraded so that it is portable.
- The application can be moved between servers easily, preferably at the touch of a button
- That multiple developers can work on the application at the same time
- That all external services like version control or issue tracking which support the application are owned by you, not us or your other developers
- You are not tied to any single service provider or developer
What do we get if Siftware makes our application portable?
Precursor: fact finding
We can’t undertake any work for you without knowing some basics about your application. So we conduct a fact finding exercise.
We may have already done this for you by providing a full risk analysis for your web application. If so you’ll already know that our report service results in a comprehensive analysis of your current system, providing recommendations for improvements prioritised by the risk to you or your users. This includes server & application security, coding practices, monitoring, web application disaster recovery as well as the infrastructure around your application that enables new features to be added, to include: how are feature requests handled, where does the code get stored & how are deployments made?
If we have not already done this for you then we’d draft a simplified version of this document with a focus on the current hosting as well as the development workflows.
Armed with either of these reports we’d then have a good enough understanding of your system to make any required architecture improvements.
The first thing we do is get you a robust development version of the website that can be used by any competent developer to ‘spin-up’ a fully working version of your system ready to be developed on by them, using their computer and their favourite development tools.
The development system makes use of high quality free and open source software that will work on any modern operating system such as Apple’s OSX, Microsoft’s Windows or any newer version of the Linux desktop, like Ubuntu or CentOS.
By running a single command the servers are created as virtual machines, all server packages are installed and the system is configured to accept your application. Any databases are created and populated with test data and the application’s code is then loaded onto the machine.
Your developer is thus presented with your full application running on their machine and, most importantly, the version they have to develop against is identical to the version running on your live server, right down to server operating system and specific software package versions. It’s a full mirror image running on their computer.
You’ll already have hosting for your live application. If there have been no problems found with this then we’d continue working with your current set-up as-is.
If we find that the server – or indeed multiple machines for a more complicated set-up – require some improvement, for example the operating system or packages are quite out of date or because there is more than one version of the application running on the same machine, then we may suggest that the application is migrated to a new machine so we’re starting from a clean slate.
We are not wedded to any given hosting provider and have no vested interest in recommending one provider over another. As long as they can provide you with a secure hosting environment, good and timely support when it’s needed and ideally management services like regular patching and back-ups then we are happy to work with your current supplier.
If you are unhappy with your hosting provider or they are found to not deliver what we’d consider to be basic services then we will provide you with some cost effective recommendations.
Assuming that we’re sticking with your current hosting provider we would now use our provisioning scripts to create you a production (live) version of your web application.
The development server is created – provisioned to use the technical term – using scripts crafted by us to build a mirror of your production environment. Once these scripts are written and are proven to be working we will then optionally re-use them so that we are able to run the same routines on your production hosting. This will make sure that all packages are installed, with the correct versions.
As well as removing error – we know that the servers are identical because they’ve been created using the same routines – you will now always have the ability to quickly build a new machine should the worst case scenario happen and a server needs a complete re-build. There is no second guessing, no getting tripped over about an undocumented configuration option, it’s a simple re-run of the same routines used to build the developer’s version.
Version control allows multiple developers to work on the same application, even on the same feature, at the same time without having to worry about over-writing other people’s changes. It also means that a detailed log of any code changes is available and makes possible ‘rolling back’ to previous, known to be working version of code should a bug subsequently be discovered in a newer version.
Version control is essential for any modern web application and if it is not currently being utilised we will suggest a cloud based provider that you can use to securely store your code so that it can be accessed by any developer with an internet connection.
As with your hosting you will directly pay any licence fees to the provider and we’d get it all set-up for you.
It is a basic requirement for any modern web application to have a test version of the system to allow you to check any changes that are made to the system before putting them live.
If you don’t already have a test version of your system we will get you one set-up. This will be a simple task as we will once again re-use the provisioning scripts already built for production and development.
You will pay any additional hosting fees for the test server directly to your current hosting company and we’ll then get it all set-up for you.
Once a new feature has been developed or a bug has been fixed then those changes need to be deployed. Firstly to the test server and ultimately to your production server.
Manual deployment using a tool like a secure FTP program is prone to error. Files can be missed, or placed into the wrong location and this can be hard to debug. It’s also slow and can sometimes leave an application in ‘limbo’ state with the application ceasing to function and reporting errors to your users until all of the new files are deployed.
To remove any chance of errors we create scripts that will deploy changed code directly from your version control system up to the relevant server. Once all the files are transferred, backups are created of the existing code and database and then the web server software is re-pointed to the updated code location.
This approach also ensures that the system can be quickly reverted to the previous version if problems do occur with the new release after deployment.
Any complex system will usually have a list of new required features or bugs that need removing. You may currently track these using a word document, a spreadsheet or even in something that your developers have put together for you.
The problem with tracking enhancements – your feature backlog – with these methods is that it can be difficult to share and most importantly collaborate on them.
We advocate using a professional issue tracking system that not only allows all relevant stakeholders to view and prioritise the most up to date list, but to also clarify any points that are unclear. Not only does this mean that there is a healthy flow of communication around any new feature or fix, but that there is a single, centrally stored narrative relating to each change to your system that can always be referred back to.
We can provide you with access to our preferred task management system or we can get an account set-up for you in your name. The former option is free for ongoing clients with support or development retainers and the latter would require you paying a licence fee directly to the provider, we’ll then get it set-up for you.
It is worth noting that with the former option it is possible at any time to export the entire feature list and any comments to a new instance in your name. This means that whilst working with us you could benefit from reduced licencing fees but should you build your own team in-house or simply decide to switch to a new development provider, you are not tied to us.
By this point you’ve got a working development, test and new live server with provisioning (server creation and configuration) scripts, deployment (build) scripts, a version control system and a place to store your feature requests.
If we’ve built you a new production machine then the last thing that we need to do is to migrate to the new system. This is a relatively straightforward exercise. We’d have the old and new systems running side by side and we simply make a switch so that “http://app.your-company.co.uk” points to the newer system.
This re-pointing will not affect any email services or other websites that you might own, the only change made is for the location of the application that we’re working with.
Once the exercise is completed we will provide you with simple documentation that will cover:
- How to get the developer’s system running
- How to deploy changes to test
- How to deploy change to live
- The various locations of the different systems (remote hosting, version control, feature backlog)
This documentation will be suitable for any competent developer to use to work with your system.
You’ve now got a fully portable production system that can be worked on by any developer.
If you decide to use our services for ongoing support or maintenance then we can offer contracts that mean you have us available for as little or as much as you need us, when you need us. We can work with your existing suppliers and if required share any development work with other providers.
We can also act as a ‘bridge’ between your business and other technical suppliers. We’d take the lead in any new feature enhancements and, where specified, share this work amongst your developer pool, be that internal or external. If there is a problem with your live application you simply call us and we’ll liaise with any required external suppliers to ensure that the problem is rectified.
If you’re reading this and would like to discuss how we could help you get a portable website then in the first instance please get in touch to discuss your specific situation.
If you’re not quite ready, no problem. In the meantime you might want to consider getting hold of a copy of our free guide to managing a web application which covers these and other topics in a bit more detail.