Alpha Software is focused on enabling developers to create robust, data-driven business applications that run on any PC, Tablet or Smartphone in the fastest, most efficient and cost-effective manner possible.

Share this blog:

Monday, March 01, 2010

Why you should use a staging site for your Alpha Five applications, and how to set one up

Publishing changes to a production Web site can be nerve-racking, unless you mitigate the risk by testing first on a staging site. Here's how to set one up without needing another physical server or a second Alpha Five server license.

Unlike desktop applications, which are typically revised on a schedule measured in months, Web applications are revised often. There's a temptation to make a change in the hope that it will fix a problem. But some of the time, an ill-considered change will do nothing, make things worse, or break something else.

We advocate a widely used approach to Web development: Maintain a development site, a staging site, and a production site. Most Alpha Five developers use their own PCs as their development site. Many publish directly to their production site after quickly testing their work on their development machines. Unfortunately, that does not give a wider audience a chance to test the new site.

The use of a staging site not only helps you to test your own changes, it can help you test patches to the Web Application Server. While Alpha tests its own patches, there might be aspects of your application that differ from Alpha's test cases. Therefore, you should always test patches before you put them into production.

We've broken the process of setting up an Alpha Five staging site into seven easy steps.

1. Install a second copy of the Alpha Five server. Download a current copy of a5v10_AppServer.exe if you don't already have one, and run it. When you get to the destination location screen, change the destination folder from the default (C:\Program Files (x86)\a5V10 Application Server or C:\Program Files\a5V10 Application Server) to another location, perhaps C:\Program Files\a5V10 Application Server2. Also change the program manager group from the default (Alpha Five Version 10 Application Server) to another group, perhaps Alpha Five Version 10 Application Server2.

2. Change the port number or IP address. After installation is complete, run the new server and bring up its server settings. Change either the server port (on the General tab) or the IP address binding (on the Advanced tab) to be different from your primary server. We often put the staging server on port 8080, assuming that the production server is on port 80. If you want to use different IP addresses and your primary server has a blank address binding, you might need to enter IP address bindings for each Application Server. For your convenience later on, give each server a different systray caption on the Advanced tab.

3. Create a new Web root. Change the document root for the new server in the General tab from the default (C:\A5Webroot) to something else, perhaps C:\A5Webroot2 or C:\A5Stagingroot. Copy the contents of your normal Web root to your new staging root using Windows Explorer, xcopy, or robocopy.

4. (Optional) Create an FTP server for the new Web root. If you publish to your server using FTP, create a second FTP server instance that points to your new staging Web root. Also, create a new publication target in your Alpha Five IDE that uses this second FTP server.

5. Publish to the new staging site for testing. The next time you have changes to publish, instead of going for broke once it works for you on your development computer, publish to the staging site and ask your colleagues, the stakeholders, and your testers to run it through its paces. Give them plenty of time to get back to you with a yay or nay.

6. Apply patches to the second Alpha server for testing. The next time you have the opportunity to apply the latest server patch from Alpha, apply it to Alpha Five Version 10 Application Server2 and test your staging site thoroughly. As before, ask your colleagues, the stakeholders, and your testers to run it through its paces, and give them plenty of time to get back to you.

7. After acceptance, publish to the production site or patch the primary Alpha server. Once your testers have given your new version and/or the new Alpha Five patch their seal of approval, apply the same changes and/or patch to your production server. Lastly, test the production site to make sure that you applied the same changes as you did to the staging site.

Now you won't stay up at night worrying that you made a breaking change. By testing on the staging server first, you eliminated most of the risk involved in updating a live site.


Matt said...

"Most Alpha Five developers use their own PCs as their development site. ...Install a second copy of the Alpha Five server."

Interesting. I have been wondering how you might have two (or more!) databases open simultaneously while keeping them completely separate. Is it possible/allowed/licensed/technically feasible to install a second and poss a third copy of the whole Alpha Five app? On both your home and work machines? Will that allow two or three databases to be open simultaneously or are you going to run into problems e.g. with the preferences?

Why would you want to do this?
1) you're developing for someone else and have your own contacts/emails/diary etc in Alpha. You need both databases open simultaneously but want everything kept COMPLETELY separate. (2 instances of Alpha)

2) you're learning Alpha and want to be able to refer to various of the demo apps without having to keep closing and re-opening your live app. (2+ instances)

3) you're building a new app and want to be able to cut & paste bits from the demos or your old apps AND you need to keep your contacts/emails/diary database open too and that is also in Alpha (3+ instances).


PS As a side note, I must admit I have difficulty understanding why Alpha would store its prefs in the registry rather than a text file in the Alpha folder since the latter is far easier to backup and transport between e.g. home and work machines. Is there an easy way to back up and restore the prefs?

Anonymous said...

Maybe I misread, But it is not enough to have a seperate environment for your Application server. You need to run it against a seperate DB server also:

DTAP change management consists of:

Seperate Application server against seperate database servers for Development, Test, user Acceptance and Producton environments.

I do not see anything in this post to connect to a seperate DB environment while testing patches...

if you use the staging AS server against the production DB directly, what are you are going to do when data in your prod env is screwed up by this? Also you do not want test scenarios enter or update data there..

Martin Heller said...

I agree completely: you're raising an issue I was saving for a future post. In fact, Alpha Five makes it trivially easy to do this by customizing the database connection string for each publication target.

Trent Livio said...

thanks for this information, and the clarification on the licensing question.

Related Posts Plugin for WordPress, Blogger...