Live debugging, small bugs, how do you do it on live servers?
When the client come to you and say : that XSLT-list you made for us, with this and that, it does not work 100%. Please have a look at it right away! You think, ah, must be some minor mistake. How do you take care of it? Debugging the fix on your dev machine, subversioning the corrected file(s), copying it to staging, and then copying it to live server? Or going to the live server and fixing that tiny error in a minute, perhaps risking yet another error while testing. (Of course it depends on the info importance and size of the site, but for standard information on a average company / organization site).
If this show that I am a sloppy coder then please forget this post, and do not show it to my clients. :-)
Ideally, you want to have at least 3 environments: dev (local), staging (test) and production (live). Obviously, not all websites follow that set-up - either due to lack of: time, money or experience/knowledge. (Like I say, this is an ideal).
Although it's tempting to fix/tweak things on live (easier/quicker), don't do it. Try to fix on dev, test it, commit to repo, deploy to staging, test it, release to production.
But no one is perfect, I have many clients who have a live site - and that's it - with my dev version backed-up on some external HDD somewhere?!
So what to do? If you want to fix the bug without anything else breaking, then I'd suggest taking a copy of the live site (Umbraco install + database, along with anything else it uses, web-service references, etc), and restore it locally (dev). Fix the bug, once it's done, release back to live.
Again, this is all down to how much time, effort and money your client wants to spend. i.e. if they are paying you peanuts, then doubt they'll care about "best practices".
There are many many ways to tackle it... I'm interested to hear what other Umbraco devs are doing.
Thank you for your thougths. I did consider to apply such a method you suggested for all my work, but it's really a bit slow (perhaps due to lack of a good automatic dev2deploy-method).
I decided to look at my role in the project right now as of a mechanic working on-site or close to the site (with a running machine), not as part of the constructing + assemby team in the "site factory". I really need a quick way to fix / tweak things my customer reports / wishes. And we have daily contact when we discuss small changes and improvements. Most of the time I like to see my job here being on almost the same level as the editors considering what page hierachy and name they should use for new or changed pages.
So for minor XSLT-fixes I do like this 1) I fix the bug/approvement on the staging site, get it verified by the client and 2) copy the xslt to the live site. Also, I 3) regulary (not after every change) copy the changes to dev + commit them to the repository where they should be for security and versioning.
For big improvements and new additions to the site I do 3) and move myself to the factory, working on the dev installation.
Here's how I would do it... not that I would ever recommend anyone work on a live site, mind you ;)
You've got an xslt macro that needs a little tweak, but it's a live site and you don't want anyone to see what you're doing until you're SURE it works properly. There are three ways to tackle this on a live site...
XSLT Visualizer (my favorite!) Make changes to the xslt file but DO NOT SAVE the file. Instead, select all the text in the xslt file and click the 'Visualize XSLT' button in the toolbar. If your macro depends on the $currentPage parameter then choose a page in the content tree that is relevant for your macro. You'll see the output in the popup window. Edit the xslt, select all, visualize the xslt. Repeat until you're happy with it. THEN you can save the xslt file and the site is updated.
Hidden Content Page If the macro is embedded in a richtext editor then you would want to copy the xslt file's contents to the clipboard and create a new macro. Paste the old xslt content into the new xslt file. Right-click the existing content node that uses the macro and 'Copy'. Be sure the 'umbracoNaviHide' is selected before you publish the copied page so it doesn't appear in any navigation. Change the macro to your new macro, update the xslt until it works properly, and confirm it by viewing (not previewing) the page. When you're happy with it, copy the xslt back into the original macro. Then delete the copied content page, macro, and xslt file to clean up after yourself.
Alternate Template Very similar to the hidden content page, but works when the macro is in the template itself rather than embedded in the RTE. Copy the template with the macro in it. Duplicate the xslt and macro so you have a working copy to play with, just as with the hidden content page. Update the copied template to use the new macro. Then, use the ?altTemplate= syntax to see the result of your work. For instance, if the /about-us.aspx page had your macro in it and your copied template had an alias of 'about2' you'd use the url: http://exampple.com/about-us.aspx?altTemplate=about2. Or, using the shorthand url for an altTemplate, http://example.com/about-us/about2.aspx.
I always, always, always have at least three environments (dev, staging, live).
Do your changes in the dev version first
COMMIT to the repository (!!) - important for tracking changes and reverting them
Deploy to staging and confirm that it still works, then get the client to approve the change. (If it's a minor change, I might skip the approval step, but i do, ALWAYS check if my change works exactly the same as I expect it to on the staging server)
Then deploy to the live server and test, test, test
I have a really easy deploy script (that I should blog about soon). It takes advantage of the fact that I can use terminal server to connect to my staging/live server.
This process takes hardly more than a few minutes of extra time, and the extra time is absolutely worth it, having good change tracking in place is the most important thing I've ever done in development. Being able to easily go back to a different point in time or just to see a diff between source code between yesterday and today is extremely convenient.
I could write a whole essay on this... ;-)
What it comes down to: It sounds like a lot of work, but once you set up all of your projects like this, it is not. There will always be a one-time investment in setting this up properly, but after that, you reap a lifetime of benefit from that investment.
I completely agree with Sebastiaan about the value of proper development, QA, and rollout procedures and environments. I don't recommend what I suggested as a way anyone should work. But if you must do it live, at least be as careful as you can be by using one of the techniques mentioned. And while we're on the subject... don't forget backups! Disaster from a foolish mistake can strike quickly, especially when you're in a hurry and that's why you're working on a live site. Okay? Okay.
"What it comes down to: It sounds like a lot of work, but once you set up all of your projects like this, it is not. There will always be a one-time investment in setting this up properly, but after that, you reap a lifetime of benefit from that investment" & "don't forget backups" words of wisdom.
I'd sure like to make that "investment", it will require quite some steps, including copy the live db to dev & staging (q about that - can one run the staging site against the live db?). Much of this points me to the direction of buying Pro, but even so I & many more sure would like a simple as possible method without Pro.
Also I think of ppl doing a basic site, probably with Creative Website Starter, being "site builders" only (umbraco tv-terminology).
Live debugging, small bugs, how do you do it on live servers?
When the client come to you and say : that XSLT-list you made for us, with this and that, it does not work 100%. Please have a look at it right away! You think, ah, must be some minor mistake. How do you take care of it? Debugging the fix on your dev machine, subversioning the corrected file(s), copying it to staging, and then copying it to live server? Or going to the live server and fixing that tiny error in a minute, perhaps risking yet another error while testing. (Of course it depends on the info importance and size of the site, but for standard information on a average company / organization site).
If this show that I am a sloppy coder then please forget this post, and do not show it to my clients. :-)
Regards / Jonas
Ideally, you want to have at least 3 environments: dev (local), staging (test) and production (live). Obviously, not all websites follow that set-up - either due to lack of: time, money or experience/knowledge. (Like I say, this is an ideal).
Although it's tempting to fix/tweak things on live (easier/quicker), don't do it. Try to fix on dev, test it, commit to repo, deploy to staging, test it, release to production.
But no one is perfect, I have many clients who have a live site - and that's it - with my dev version backed-up on some external HDD somewhere?!
So what to do? If you want to fix the bug without anything else breaking, then I'd suggest taking a copy of the live site (Umbraco install + database, along with anything else it uses, web-service references, etc), and restore it locally (dev). Fix the bug, once it's done, release back to live.
Again, this is all down to how much time, effort and money your client wants to spend. i.e. if they are paying you peanuts, then doubt they'll care about "best practices".
There are many many ways to tackle it... I'm interested to hear what other Umbraco devs are doing.
Cheers, Lee.
Hi!
Thank you for your thougths. I did consider to apply such a method you suggested for all my work, but it's really a bit slow (perhaps due to lack of a good automatic dev2deploy-method).
I decided to look at my role in the project right now as of a mechanic working on-site or close to the site (with a running machine), not as part of the constructing + assemby team in the "site factory". I really need a quick way to fix / tweak things my customer reports / wishes. And we have daily contact when we discuss small changes and improvements. Most of the time I like to see my job here being on almost the same level as the editors considering what page hierachy and name they should use for new or changed pages.
So for minor XSLT-fixes I do like this 1) I fix the bug/approvement on the staging site, get it verified by the client and 2) copy the xslt to the live site. Also, I 3) regulary (not after every change) copy the changes to dev + commit them to the repository where they should be for security and versioning.
For big improvements and new additions to the site I do 3) and move myself to the factory, working on the dev installation.
Kind regards/
The Umbraco-site-mechanic
Here's how I would do it... not that I would ever recommend anyone work on a live site, mind you ;)
You've got an xslt macro that needs a little tweak, but it's a live site and you don't want anyone to see what you're doing until you're SURE it works properly. There are three ways to tackle this on a live site...
XSLT Visualizer
(my favorite!) Make changes to the xslt file but DO NOT SAVE the file. Instead, select all the text in the xslt file and click the 'Visualize XSLT' button in the toolbar. If your macro depends on the $currentPage parameter then choose a page in the content tree that is relevant for your macro. You'll see the output in the popup window. Edit the xslt, select all, visualize the xslt. Repeat until you're happy with it. THEN you can save the xslt file and the site is updated.
Hidden Content Page
If the macro is embedded in a richtext editor then you would want to copy the xslt file's contents to the clipboard and create a new macro. Paste the old xslt content into the new xslt file. Right-click the existing content node that uses the macro and 'Copy'. Be sure the 'umbracoNaviHide' is selected before you publish the copied page so it doesn't appear in any navigation. Change the macro to your new macro, update the xslt until it works properly, and confirm it by viewing (not previewing) the page. When you're happy with it, copy the xslt back into the original macro. Then delete the copied content page, macro, and xslt file to clean up after yourself.
Alternate Template
Very similar to the hidden content page, but works when the macro is in the template itself rather than embedded in the RTE. Copy the template with the macro in it. Duplicate the xslt and macro so you have a working copy to play with, just as with the hidden content page. Update the copied template to use the new macro. Then, use the ?altTemplate= syntax to see the result of your work. For instance, if the /about-us.aspx page had your macro in it and your copied template had an alias of 'about2' you'd use the url: http://exampple.com/about-us.aspx?altTemplate=about2. Or, using the shorthand url for an altTemplate, http://example.com/about-us/about2.aspx.
cheers,
doug.
Oh my guys, this is making me cringe.. ;-)
I always, always, always have at least three environments (dev, staging, live).
I completely agree with Sebastiaan about the value of proper development, QA, and rollout procedures and environments. I don't recommend what I suggested as a way anyone should work. But if you must do it live, at least be as careful as you can be by using one of the techniques mentioned. And while we're on the subject... don't forget backups! Disaster from a foolish mistake can strike quickly, especially when you're in a hurry and that's why you're working on a live site. Okay? Okay.
cheers,
doug.
"What it comes down to: It sounds like a lot of work, but once you set up all of your projects like this, it is not. There will always be a one-time investment in setting this up properly, but after that, you reap a lifetime of benefit from that investment" & "don't forget backups" words of wisdom.
I'd sure like to make that "investment", it will require quite some steps, including copy the live db to dev & staging (q about that - can one run the staging site against the live db?). Much of this points me to the direction of buying Pro, but even so I & many more sure would like a simple as possible method without Pro.
Also I think of ppl doing a basic site, probably with Creative Website Starter, being "site builders" only (umbraco tv-terminology).
I really appreciate your thoughts here,
Kind regards,
Jonas
is working on a reply...