Developing for the Web - Best Practices

Here at the Science Museum of Minnesota we have a pretty nice setup for Tessitura web development and testing:

(first note: we're running virtual machines for our Tessitura servers)

- Identical IIS web server for development links to:
- Identical Tessitura development database (we sync the data from live to dev every couple months or when major development needs to happen/be tested)
- Development website that is a duplicate of our main website. I update the data from live to dev about once a month. The website is only accessible via our internal museum IP address and any others we let in (our web development firm, etc.)

It's worked great for us; both for developing new Tessitura web functionality and having end-users play with the website to see how Tessitura interacts with our web.

Hope that helps!

Eric Mueller
Webmaster & Social Media Guy
Science Museum of Minnesota
emueller@smm.org
(651) 221-9455

Hi Matt

We use a similar setup to Eric. Possibly more complex, because we're dealing with a consortium context, with five separate orgs independently developing websites to point at our system.

We maintain three test Tess environments, and each of them is complete - that is, for each environment, there is a full set of components, including an API. Our live API is set up on a load balanced pair of virtual servers, and there is a separate pair of load balanced virtual servers which hosts all of the test APIs (and a warm backup of the Live API). On a similar pettern, we maintain two domains (Tessgateway and Tessgateway2), with the primary pointing at the Live API host, and the secondary  pointing at the test APIs host. We punch holes in the firewalls to give web developers access as needed.

One of the test environments (Test2) is more or less devoted to new-version testing, although it is used for other things when there is no new version on test.

The individual web developers can choose to point their dev websites at any of the environments, depending on where they are in the cycle. Mostly at the normal (Test) environment, but recently, for example, our partner Opera Australia did a website re-design which was scheduled to go live just after we were scheduled to do the v10 upgrade, so they developed pointing at Test2.

Another of the test environments (Model) is refreshed from Live overnight, every night, so it gets used for final checking, to ensure that any setup needed has been done in Live, before switching it on. 

That all works fine. We've never had a problem running multiple APIs - you do need to keep an eye on the web.config files, to make sure that any changes in testing there are repeated in Live, and of couse if the API itself is extended in some way. Developers have a habit of forgetting about that stuff for some reason. And when there's an issue to resolve, people can sometimes get confused about which environment they're working in (or at least, they can forget to tell us they've changed)

For our own website, we maintain separate dev/test sites which duplicate the live setup as closely as possible, including using multiple virtualised servers smeared across multiple physical servers.

Ken

Thanks for the responses.  We actually do pretty much exactly the same thing with our development process.  We are looking into creating a local environment such that you don't even need an internet connection to be able to do the testing; i.e. you run all the services and such on your local box.  Our gateway server can only be accessed from our website, so connecting directly to the API from the internet at large isn't an option.  Right now I can use a development environment within the firewall, but we have a development group that aren't all going to be able to do that.

Thanks for the responses.  We actually do pretty much exactly the same thing with our development process.  We are looking into creating a local environment such that you don't even need an internet connection to be able to do the testing; i.e. you run all the services and such on your local box.  Our gateway server can only be accessed from our website, so connecting directly to the API from the internet at large isn't an option.  Right now I can use a development environment within the firewall, but we have a development group that aren't all going to be able to do that.