Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialJoe Consterdine
13,965 PointsBest Practises For Working On a Live Site?
Hey guys,
quite new to working with clients and have found a little uncomfortable working with other peoples sites haha!
My worst nightmare is messing someones site up.
I obviously understand about using Git, we use Source Tree where I work and I'm still getting used to that to be honest.
Sometimes when there's small changes to be made on the site I simply backup the site on my local computer and then make the changes via filezilla.
However that still seems a bit risky.
I guess it comes down to experience but is there any rules you stick to during this process?
Thanks!
2 Answers
Mark Hatting
1,017 PointsWhat I typically do is this:
- Never, ever, ever, make changes to a production site without client approval first. I always make a complete backup of the site on my local machine, including any database backups. I then make the changes on my local machine.
- I then create a remote staging environment where the client can approve changes that I make without it being publicly accessible. The easiest way I found to do this is via an .htaccess file.
- After the client approves it, I publish those files (and only those files to the remote live server). I use Coda as my dev tool, which has a nifty feature that keeps track of what files have been modified since last saved. Coda also has built-in SCM that integrates directly with Git (local and remote branches).
- After the files have been published, I push them to my Git repo for that site. I also use SourceTree and Bitbucket to keep track of my repos, and I still find it a bit confusing, but I'm getting the hang of it. I find it easiest to merge push requests via the web interface in Bitbucket.
Codin - Codesmite
8,600 PointsNormally when working with live production sites I will not directly make changes to the website.
- First I will download a full backup of the current website to my local machine via FTP.
- Make a backup of any databases for example mySQL (Also copying and setting up a version to my local machine).
- I also as a side measure create a subdomain location on my own website/webserver and upload the database backups to the webserver (This allows me to test a working version on all my devices, for example I don't really want to run SQL Server, Apache, PHP etc on my laptop, so having space on my own webserver for the test version of the website allows me to quickly test the website by directly uploading changes from my IDE or text editor).
I will never upload to the clients server before the finished version is complete and will always wait for clearence to do so from the client.