12 replies to this topic

[Cris D.]

After doing a search of the etomite forums, the "staging" solution seems to be just create your pages in an unpublished repository until you want to make them go live when you move them. Of course, now days it is probably a better option to just use the "Show in menu" option. However, with a site that has lots of custom php snippet code in it and it is in production, how does one develop and test on a mirrored site then deploy the changes to the production site confidently?

In the past, I have worked on a localhost and documented the changes then deployed the changes and kept my fingers crossed that they worked on the live server and that I diddnlt miss anything. I don't think this is good enough if you have customers trying to purchase from your site while you do this "upgrade". I have also developed on one server and deployed to another server but as the tables grow there will be issues with using a back-up and restore method as well as cross server diffences again.

Ideally there can be a mirror of the site on the same server so all development is identical to the production environment. However, how does one do this and stop anyone from accessing it?

Here is a visual representation of a development and staging environment from DLTJ so the concept is clearer.
 deployment_plan.gif   61.63K   26 downloads

Etomite Community:
What methods of pre-production staging have you used with an etomite site and what level of success did you have with it?

Edited by Cris D., 03 May 2008 - 12:11 PM.

[PaulD]

Hi Cris.D,

Sorry I can't really help (as I am an amateur), but I generally upload and cross my fingers too. This has been a problem in the past when it has gone wrong.

By the way, your posted diagram is cool. But check this one out http://www.levenez.c...ng/history.html

Paul

[Cris D.]

I guess from that response (136 views and 1 reply) that most (if not all) Etomite users fall into the 1/3 of all users that do not use a staging environment or don't do pre-release testing in a realistic simulated production environment. The more I think about it and the more I research it, the better i understand why this may be the case. It seems that unless you have software the handles versioning, migration and rollbacks, there is no "automatic" way to handle this. There seems to be a lot of cross-server and documentation (or memory) finger-crossing going on!

So I'm guessing that the most common action is to develop and test on a localhost (or actually on production ), upload the changes to the live host (if they aren't there already) and start testing while others are using their site. Setting a site to "Off-line" means you can't test. - it's what I do now.

I wonder what people will think when they see a snippet dump across the top of the page while they are thinking about purchasing that book?

Surely there's a better way! What about binding the site to an IP or a different port or perhaps a different URL when the site is set to "Off-line" so it can still be viewed by authorised developers and everyone else gets the off-line message?

[PaulD]

What cubecart do is to show the offline message, unless you are logged in as an admin, in which case the site shows as normal. That works great. An option in the general settings turns it on or off, with a little text box so you can write the message to show. I usually write something as accurate as possible including the date and time it went offline and the expected date and time at the latest that it will be back online, usually ten or 20 minutes. In eto you could do a whole page with an email me when your back up button etc.

Could a simple snippet like 'is user logged in? if not return 'not up' page, if so then carry on showing the rest of the page? Then when appropriate you could just add the call at the top of a template. Or have it (in the case of multiple templates) in all the templates anyway, but harcode an option in the snippet to either run the 'check and redirect' or not.

Could a simple htaccess file not redirect every call except from, say, your ip address?

Paul

PS I suspect that a user, upon seeing a php error like that, would immediately leave the site and look elsewhere. When some of my sites go down I get mad, panic emails from irate/terrified users convinced that 'something weird' has happened and that their computers have never been the same since etc etc.

PPS I once emailed 23,000 customers the acount details and passwords for user number 1 in the list. My inbox was in overload for about two weeks afterwards.

Last one - PPPS In defence of the upload and fingers crossed people, I do it when there are no useres, late on sunday night say, and usually it involves things that you can instantly or quickly see if it has worked or not. Plus I make sure that to return to the original configuration is as quick as it is possible to be, having say files ready to upload and overwrite, or even just rename.

[Cris D.]

Could a simple htaccess file not redirect every call except from, say, your ip address?

.htaccess files are not my stong point I don't really know what they are capable of and find it as easy to write a htaccess rule as reading regex, also, they are no good for some servers and I like to come up with globall userful solutions to share, but I'll have a look at it as an option.

Last one - PPPS In defence of the upload and fingers crossed people, I do it when there are no useres, late on sunday night say, and usually it involves things that you can instantly or quickly see if it has worked or not. Plus I make sure that to return to the original configuration is as quick as it is possible to be, having say files ready to upload and overwrite, or even just rename.

I hear you, that's fairly easy to control. I'm really talking about a change in a class (or something similar) that underpins much of the site's functions and several dependant snippets that all need to be updated before the class can be tested- then there are multiple -difficult to manage, dependant changes which would take some time and documentation to revert.

I think the snippet check in the template is a great idea (but could cause issues if your site (like mine) uses several templates)... although the javascript redirection in the manager that displays the off-line page could be tweaked to allow logged in admin to view the site. I'll look into it and see what I can come up with...
Thanks for the ideas.

[Mukke]

well in my company we just make sites on a dev server and transfer them all at once for the deadline.
When they want updates we but or client for a the choose:
- site couple hours offline so we have time to update all files (we made locally or on dev server)
- no update but new site with new data changing takes several minutes (not possible for e-shops ofc)

making the site a couple of hours offlines gives you time to make sure everything is ok
you only do that when you need fast security updates or when you do big coding updates that change stuff were people can get in conflict if you don't go down..

Anyway on development stage the site is a mess, then we have testing stage were clean up and then live stage

[Cris D.]

OK I'm guessing that this will come down as an "Unofficial manager mod" and I would wait for ralph to verify that this is OK to do, but here is my solution for testing on a live site:

Change in the index.php file, the checkSiteStatus() function to also check if an admin is logged in (in the currrent session).

function checkSiteStatus() {
	if($this->config['site_status']==1) {
	  return true;
	} elseif(isset($_SESSION['validated']) && $_SESSION['role'] ==1) {
	  return true;
	}else{
	  return false;
	}

}

What this does is: if you log into the front-end using authenticate_visitor, then redirect your site visitors to a valid "Offline Page" using the document id in the offline site message; If you have logged in as the admin user (role 1) you will be able to surf (and test, develop etc) on the site and everyone else will get the offline message.

To be sure, I would create a new template called "offline" that uses a minimum (if any) snippets so that it returns as expected while you test and develop.

[Ralph]

I just had this conversation with someone last week... The Etomite manager does have an Offline option but it may not always suffice because DB updates could be in process or files might be being uploaded which could cause errors if pages are parsed... In some instances it might be better to actually use an index.html file, for example, to let people know the site is down during upgrades... This becomes more of an issue with high traffic sites... Sites with lower traffic could be upgraded on off-peak times without issues... It is definitely something I am kicking around for the next major release...

[darren]

I do my eto installs in a folder on the live server with a temporary splash page... then when all's approved/functioning just move everything out of the folder, make changes to the etomite configuration (remove folder name from path and url settings) and i'm done.

This 'testing' area is not protected in any way but unless someone knows the folder name they can't find it... I like where this is going though.

[Cris D.]

Thanks for the continued feedback.
I'd like to hear from more users if there are anymore new processes used not mentioned.

This 'testing' area is not protected in any way but unless someone knows the folder name they can't find it

I thought about that, my "testing" site has been "live" now for months and search crawlers are finding it. Unfortunately 150 people have found it. This shows a less than good image for the brand and they *may* be seeing php and sql I don't want them to knw about. Also, the index.html page is a great idea except for those who have bookmarked pages or have different entry points, they will get an error 404 instead of an offline redirection- not a good look if they are expecting to see all their hard work they have done and are not explained why their home page is missing.

That's why I was looking for a staging environment, failing that, a site-wide conditional redirect.

[Dean]

This snippet may be of use for you - it's what I use.

http://www.etomite.c...mp;showfile=209

If you enter the developer's IP into the snippet, it means that the developer will be able to see the site, but the others will receive the other html defined within it.
Don't get me wrong, it's not a perfect snippet - but it doesn't need any etomite wizardry (like permissions or sessions) ... it only checks against authenticated IP's.

[darren]

I thought about that, my "testing" site has been "live" now for months and search crawlers are finding it.

another additional step, but robots.txt takes care of that.

# block development directory /DEV/
User-agent: *
Disallow: /DEV/

[Cris D.]

I found a way to create a pretty close pre-production environment that is secure and safe. One of the biggest problems with setting up an environment is all the variables and options. Below is the culmination of 2 years of searching and tweaking and trying various solutions. This one actually works (for me) very well, stable, simple and quick (once it is set up).

Although not a true pre-production (as it actually resides on another server), but I have found this process to be simple and have not had any problems with it yet... I have listed the specs at the end of this post. All URL's to the free software I have referred to in this post can be found in myBlog.

My host (a LAMP- Linux, Apache, MySQL, PHP) provides "Home Directory" and "Database" back-up buttons. When clicked, the database is backed up as a .gz (150kb) file and the Home Directory is compressed into a .tar.gz (4.5Mb) file. Now at this stage I have a full backup of all files and database in the site. This takes about 4 minutes and there are other ways of doing database backups and ftp'ing files for back-ups...

Then using the xampp (I used the windows version with the installer) which can be downloaded for free from apache friends:

As you are installing it, install apache and MySQL as services.

Turn on FURL's on your localhost:
Navigate to the xampp/apache/conf/httpd.conf, open it with a text editor and uncomment the:

LoadModule rewrite_module modules/mod_rewrite.so

to turn on Friendly URL's (FURLS) -if your downloaded site uses them.
Downloading and installing this software takes about 15 minutes- but you've now got your own local server.

Next, extract the backed up files using something like Universal Extractor (downloadable for free). Extract them to a sub-directory. Navigate inside the extracted files to the public_html folder, go inside that and copy all the files and folders inside.

Navigate to your xampp/htdocs/ folder. Create a new folder in the name of your site eg: pp.mysite.com.
C:\xxamp\htdocs\pp.mysite.com\

Paste all the files and folders into this new folder (or ftp a back-up of your site to this folder). Now all your files are on the local server, all you need to do is create your database.

In xampp (type "http://localhost" into your browser to access it). Navigate to PHPMyAdmin (the default username is root and the default password is 'NULL' (that is nothing, or blank). PhpMyAdmin>Home>Create a new database (with the same name of the one you have on the live server). (If you are not sure, have a look at the file: manager/includes/config.inc.php (open it with wordpad or an IDE) and look at the database details:

// Etomite database connection parameters
$config_release = "1.1";
$database_type = "mysql";
$database_server = "localhost";
$database_user = "username";
$database_password = "secretPassword";
$dbase = "`account_database`";
$table_prefix = "etomite_";

PhpMyAdmin>Home>Privileges> Add a new user with the same name and password as your live site and assign the user to the database you created (don't give more rights than your live site has, otherwise you run the risk of creating code that is not useable on your live site).

PhpMyAdmin><yourdatabase> >Import> Navigate to your .gz (or other export from your database) backup file and import it.

Open your site in your browser (http://localhost/pp.mysite.com/manager )

Log into your etomite manager, clear the site cache, save the site configuration settings and you now have a mirror of your site that you can continue development.

If you stuff it up beyond repair, simple drop all the tables in the database and re-import the .gz file, and re-copy and paste all the files from the .tar.gz extracted folder, and you have a clean mirror of your site again.

Once you are happy with the changes to your site, you can ftp up the contents of the xampp/pp.mysite.com folder and do an export and import of your database to make the changes (or just implement the additions manually once tested if you are more cautions or if there are only a few changes).

This process has worked so well (and this is probably not the recommended method of tackling an upgrade) that I had a pre-production 0.6.1.4 and a live production V1.1 and when I followed this process, my local pre-production 0.6.1.4 was upgraded to V1.1, without a hiccup!

A word of caution: Both sites should be as similar as possible, and all site links should be dynamically created. I also do not use wysiwyg editors or anything else that requires an absolute path. If this is you, you may have to spend some time tweaking these things to work inside the etomite manager. Also, hardcoded urls will obviously not work as the site links should have "http://localhost" pre-pended to it, but seeing I always use dynamically generated URL using $etomite->makeURL(), this is not a problem.

Hope someone finds this useful.

The specs:
Live host:
Apache version 2.2.6 (Unix)
PHP version 5.2.5
MySQL version 4.1.22-standard

Localhost:
Toshiba Laptop running
Windows XP SP3
1.4GHz, 752 MB RAM (not a blazer as you can see)
Compatible in all browsers
xampp Version: XAMPP for Windows Version 1.6.6a