Community Forums › Forums › Archived Forums › General Discussion › Workflow – from development to deployment. Need advice!
Tagged: git, local server, workflow
- This topic has 9 replies, 4 voices, and was last updated 9 years, 10 months ago by
coralseait.
-
AuthorPosts
-
March 24, 2015 at 5:57 am #145444
sethbahookey
MemberHey Everyone,
So as I've been getting more familiar with WP and Genesis. I've come to realize I'm a total cowboy coder i.e. making development changes to my live site without testing it out on a dev site first. This has made me take a step back, and really think about fleshing out a workflow plan before I actually take on some real clients.
Ideally, I'd like to work locally on my sites first. I was think about using Git so I could push my changes to the live site, but I was also wanting to work on my sites across multiple computers to i.e. my desktop and laptop (both PCs).
I found this article that seemed like a perfect solution.... http://code.tutsplus.com/tutorials/wordpress-development-and-deployment-with-mamp-git-and-dropbox--wp-25718 ...until I read the comments below and everyone was complaining about how in accurate the article was 🙁
I also found this lady's workflow http://ameliabriscoe.com/import-a-wordpress-git-repository/ that could potentially seem good, but after watching it I felt like there were a bunch of holes in her methodology, and I also wouldn't know how to use Genesis with the way she installs themes.
I've now come to the forums asking you all for your help. What is a good workflow that will allow me to always work on my site locally then allow me to push it to the live site (I'm assuming git, but I need an actual process to it, I'm still new). And yes, I'm familiar with Mark Jaquith's skeleton repo, but he is way above my skill level, and talks way to technically for me to understand how he does it (although I'd imagine his way is pretty good). Here's the link just in case. http://wordpress.tv/2011/08/20/mark-jaquith-scaling-servers-and-deploys-oh-my/
Thanks!
March 24, 2015 at 7:14 am #145449Victor Font
ModeratorTruthfully, lol, I think you need a copy of my book The Ultimate Guide to the SDLC.
Regards,
Victor
https://victorfont.com/
Call us toll free: 844-VIC-FONT (842-3668)
Have you requested your free website audit yet?March 24, 2015 at 7:50 am #145459sethbahookey
MemberCould you tell me a little bit more about why I should purchase your $70 book? Does it have a step by step guide on how to setup WP w/ Genesis locally across multiple devices and then allows me to push to a live site?
I went to Amazon and previewed the book and I wasn't seeing anything like that. So please help me understand 🙂
March 24, 2015 at 11:06 am #145489Victor Font
ModeratorMy book is not about Genesis. It's about professional IT practices. I was only joking with you.
Regards,
Victor
https://victorfont.com/
Call us toll free: 844-VIC-FONT (842-3668)
Have you requested your free website audit yet?March 24, 2015 at 11:07 am #145490sethbahookey
MemberOh I see.. well thanks anyways.
March 24, 2015 at 5:16 pm #145541coralseait
MemberWe've taken a different approach and vastly simplified our process. This works for us, and is not the be all end all, but after trying various workflows we've settled on this.
We use dev environments that mirror exactly what production will be; no using mamp or 'local' versions, 'laptop dev', local lamp / lemp etc. We have these environments setup for our shared hosting partner(s) and our VIP VPS services.
We develop on dev.url.tld and use UpdraftPlus to push changes to production via search and replace. Having reviewed things, we've found that storing all clients' sites in Google Drive and S3 using Updraft to migrate allows us to mirror exactly what things will be like in live sites and eliminate problems. There is a bandwidth issue for large sites, but we accept that and feel it is better to be deving on the actual site save a url difference than attempting source control through git / source tree and all the merging, pushing, committing, etc issues. We also, as standard at no additional costs to our clients, keep at least 14 nightly backups so it is already somewhat baked into your process. We just pull the last backup or trigger a new one if necessary.
It is a simple process to trigger a full backup, copy it to a dev instance, do what we need and push it back to production. We know that we'll be pushing the site exactly as it needs to be and don't have to waste time resolving 'local dev' issues.
EDIT: Part of the reason we are comfortable with Updraft is that David's support is fantastic and so we see Updraft as a partnership that aids our development. He's always very responsive so there's a level of trust now in using the tool in such a critical way.
March 25, 2015 at 3:20 pm #145662sethbahookey
Membercoralseait - thank you so much for giving a insightful answer to this topic instead of just inserting a plug to sell something 🙂
You mentioned -
"We use dev environments that mirror exactly what production will be; no using mamp or ‘local’ versions, ‘laptop dev’, local lamp / lemp etc. We have these environments setup for our shared hosting partner(s) and our VIP VPS services."Can you help me understand that process a little bit more? Would I be creating these dev environments in the etc/host folder in windows, or something else?
Thanks again!
SethMarch 25, 2015 at 4:10 pm #145664March 25, 2015 at 5:11 pm #145673sethbahookey
MemberKellysie, nice list! It doesn't really help me understand how to create a test environment across multiple computers nor does it talk about pushing said test environment live to a live site. Any insight to that?
March 26, 2015 at 6:22 pm #145757coralseait
MemberSure no problem,
We basically have two hosting scenarios for our clients. Simple shared hosting (usually on Namecheap) and more performant hosting on VPS we manage.
Therefore we have development stacks on namecheap and our VPS. Basically that means we have hosting environments on Namecheap and the VPSes waiting to have WordPress installed and sites restored to them. We don't worry about domain / url differences as Updraft handles. When we wish to make changes, we:
1) backup the production site via Updraft to one or both cloud partners
2) Restore the site via Updraft to the appropriate hosting dev instance (either Namecheap or VPS)
3) Make the changes
4) Backup the dev site to the cloud partners
5) Restore the site to production hostingBasically we maintain dev hosting instance on Namecheap AND the VPS and are backing up / restoring. Updraft handles URL replacement so it doesn't matter if our Namecheap dev instance is something like dev.coralseait.com or dev.coralseait.com/subdomain/ and likewise the same with the VPS. (We also use managed DNS which makes things very easy, but handling via local hosts / etc hosts on OSX is simple as well).
Updraft makes this a trivially simple process. Since we trust Updraft, Google Drive and S3 we know we always have source of the production site on both the cloud partners, and we don't feel the need to deal with source management. We keep min 14 nightly backups but also keep 6 month and yearly backups in case our nightly have issues.
Were we doing hardcore software development and frequent change cycles source management would be appropriate but for websites we don't feel there's value in wasting our time on local to server / server to local push and replication. In our case it is really server to server backup / change / restore cycle with redundancy leveraged at the cloud partners.
Updraft also allows us to move a site near instantly should namecheap or our VPSes go down, we just install WordPress on alternate hosting, Install Updraft and pull the latest backup and then restore. We've done this in outages and had sites back up in minutes. Since we use managed DNS propagation takes seconds to minutes.
-
AuthorPosts
- The forum ‘General Discussion’ is closed to new topics and replies.