Tuesday 4 June 2013

On Usage of Development and Production Services

As the DataPortal is now at v2, it was necessary to move it to an environment more suitable for a production service.

The COMSC Cloud installation is being retained as a development and testing environment, to push incremental code changes to between major releases. It may be possible to open this development service to other users if demand for early access becomes significant. This is almost intentionally unstable however, as once features become stable and functional, they will be pushed to the Production server. Hopefully this 3 stage development (the first stage being a build on several virtual machines on my local machine) will mean development can continue alongside user testing of released features, without one adversely affecting the other.

To this end, we set up a new cloud instance on Amazon's AWS service. As the previous development installation had been on Ubuntu in the COMSC Cloud, it was relatively trivial to set up an Ubuntu instance with EC2 and install everything again.

I took this one step further and kept records of every terminal command typed to setup the DataPortal, and created a series of scripts which automate the installation in future. This is generally good practice, and I've heard often before amongst developers that if anything you're doing is more than trivial, or requires Googling to find the correct command line incantation, save it as a script for future usage.

So now I have a script which installs the DataPortal with almost zero interaction, which is nice. It's still time consuming, and it turns out that EC2 charges for disk I/O, but it's nice to know that future builds won't be laborious and repetitive, leaving time to consider new features and implementations. It's all about efficiency.

No comments:

Post a Comment