DOTW: Staging! How are you using it? If at all (Participation = 3+ Hero Points)

Almost every WP Managed Host is offering at least one staging environment these days; some are already moving to two, one for development and one for staging in addition to the production environment.

This week’s DOTW focuses on how are you all utilizing these environments? If at all? Perhaps you have your own flow that is more local based.

1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)
2a. If it does have staging, do you use it and what is your general workflow?
2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes
3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)

For my personal site, which is more or less just a blog and doesn’t have many moving parts, I only use staging to test out new plugins I’m considering or more significant design changes. Usually, I’ll play around a bit on staging with it until I’m happy and then manually apply the final changes on the live site rather than using any sync functionality since they aren’t usually that big or are mostly plugin/theme settings(database) changes and I don’t want to overwrite the production db.

On the other hand, we have WPMU DEV here which is a much more professional development setup using git, bitbucket, es6, APIs, and probably other stuff I’m also not qualified to speak on :smile:

Interested to see where you all sit on staging usage and development flow.

---------------------

-At least one comment = 3 Hero Points(must participate within 7 days of thread post date)
-Question #3 = Additional +3 Hero Points
-DOTW = Discussion of the Week
-Last DOTW: ACCESSIBILITY! WHERE IS IT IN YOUR CLIENT'S PRIORITIES?

  • splaquet

    ohhh... i'm interested in hearing what folks have to say on this one! i don't have the time at the moment for a write up.... hah... well actually, i guess i do! personally, i've never really had the need to use a staging environment.

    i have 1 multisite that's growing to massive proportions and i know that i'm going to have to start using one soon with it. we're going to be integrating WooGlobalCart & WooMultiStore into the multisite, so staging that seems like the smartest move. to be honest, this was one of my very first MultiSites as well. I'd almost like to rebuild the entire site from the ground up, just to move forward confidently as the multisite continues to grow. (we add a new storefront every week or so)

    i also have another *massive* webstore that i'm building (96k products massive). we're building out 3 phases for it.
    1) replace current functionality of their old site
    2) setup multiple languages & additional functionality
    3) integrate into online sales platforms (such as Amazon & Google)

    ...i've often thought about how to introduce new database elements into the staging/live site, the most efficiently. i'm looking forward to hearing back from everyone!

  • PTaubman

    This is a great question and one that will get a variety of answers based on people's expertise, knowledge, and experience!

    My current hosting companies do NOT have a staging area so I improvise and do different things. The companies I use are LiquidWeb.com and MomWebs.com. None of my clients are on hosting that have a staging area where you can one-click and get a copy.

    For development work, I create a subdomain on my main hosting site. (DigitalMaestro.com). For example, https://fpc.digitalmaestro.com/ - during development (as it is now) there is a Coming Soon page and a link for clients to get in and view the current state. They can see the progress as it is being made.

    Once dev is complete, it gets moved over to the live domain.

    At this point going forward, most updates/changes are made on the live site (gasp!) after a backup is first taken. Normally, no major work gets done this way, just plugins, theme updates, and sometimes even WP Core updates. Nothing that is too drastic will get updated live. The safety net is the backup that gets made moments before applying any updates.

    For major work and/or testing, the production site is copied down to a dev site. At this point, it would be on the client domain as a subdomain (such as dev.clientsite.com).

    WIth Gutenberg coming up, I shudder to think of the massive amount of testing that should be done. I also wonder about how clients are going to approve the cost for testing, or how they will react.

    I come from a corporate background where we had 3 environments (Dev, Test, and Prod). Development was just for us developers where we would code and test things out. The Test environment was where we would put our code and let users test. This was in an identical environment to Production with the only difference being the modules were going to be upgrading and therefore needed to be tested by the users. Once the users approve of the work, it would get promoted (i.e., copied) to Production. I liked this workflow!

    As time moved on, here in the US, SOC became a big deal (Sarbanes-Oxley Compliance). As a developer, I was not permitted to move anything to production and it needed to be moved by a third party (someone NOT able to change any code). We then had Staging directories where I would put the new code from Test and then someone else would move it to Production. Everything needed to be documented with a paper trail, audit procedures, etc. It was a good practice, but overkill (imho).

    I hope I explained this clearly! Let me know if anything needs additional explanations!

    Thanks.
    Paul.

  • Baldafrican

    Have to agree, this is an excellent question this week. I will definitely learn some practical tips from all the experts on here :slight_smile:

    Currently how we setup staging sites depends on the client. If it is a client with a lower budget we typically advocate a divi site and would then set the staging site as a subdomain on our own hosting (not ideal but can't risk using too many resources on the production hosting side as it is usually shared) for six months (warranty period). After that we offer the client an option of a maintenance plan. If they accept, we continue to host the staging site, if not, we remove the staging site and set the client free. Since the site is hosted on our hosting, we mainly use the staging site to make client requested changes before going live. We also do updates on it first although it is not as effective since the hosting environment could be different.

    For higher budget clients that want bespoke development we use all the wonderful tools from our friends at roots.io. This not only helps our workflow but ensures that the development, staging and production sites are all hosted in the same environment so things can be tested fully before committing to the production site.

  • Jaxom

    Brilliant Question Tyler Postle
    Also looking forward to others answers.

    We have a special domain set up on our Company server (not shared with clients) which is specifically for staging sites.
    We setup a sub-domain for the client e.g. testsite.w4btesting.co.uk (I know, good domain :smirk: )
    Then when the client is happy we move the site to live.
    Those clients that pay for a maintenance and support plan keep there staging sites so we can test updates and changes, those who don't are told that we will remove the staging site in 30 days from going live if they do not tell us about any issues that may arise.
    Has worked really well for the past for 5 years.

    Jaxom

  • David

    1. Who is your host
    Webfaction (best hosting I've come across in 20yrs of dev)

    2a. If it does have staging, do you use it and what is your general workflow?
    It doesnt I use a separate domain I keep for Dev

    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes
    1. Mamp, 2. Dev site on hosting, 3 live site

    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)

    I'd love to have a dev/staging/hosting environment like Flywheel but frankly its cost prohibitive in the SME sector that I mainly work in.

  • ROIverhogen

    We have a decent amount of websites to maintain and not all of those are hosted with us. Usually our changes to existing websites are not that big nor have a lot of impact so we do them on the fly.
    If it's medium big we just create a copy of the page as concept and test there.

    If it's a functionality or a big, impactful change we make a backup and make a test environment on our own server. The same goes for new websites/clients. We have a list that the client needs to fill. This way we can find the focus, styling wishes, branche etc. and get a general idea before we start making the website.

    We create a subdomain on our server where we start building the website. Wordpress offers the function to disable indexing so we can work in peace. The client gets the link to the test environment so he can follow the changes made. We continuously send a mail with updates with the changes we made and try to make changes according to his/her feedback. When the site is done we transfer it to the domain and server it was planned for and start optimizing images, pagespeed, SEO etc.

  • Artemis360

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)
    I have hosting with several different providers. I've learned a painful lesson not to put all my eggs in one basket. ChicagoVPS.net, GoDaddy, EthernetServers.com, Microsft Azure, Amazon Web Services, and a few more smaller hosting companies. The only ones that come with the ability to have a staging environment is Azure and AWS (beanstalk).

    2a. If it does have staging, do you use it and what is your general workflow?
    For AWS, I create a staging environment in beanstalk and make updates/changes to that then test it. Once good I make it the active environment and take the old environment offline. So my staging env becomes production.

    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes
    I usually take a snapshot of the server/storage and if things go south I restore from the point in time. Otherwise, a good old, backup and restore will get done if things get hosed.

    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)
    For work; it's Development environment, a Test environment with dummy data, then staging environment with a copy of the live data, then push to production.

  • Tuomas

    Most of my sites are self-hosted, so I could get as many staging environments as I ever wanted.

    But.... I still catch myself applying updates and plugins on live sites with no level of staging. I do run regular backups and take snapshots before any bigger changes, so if something goes wrong, it is relatively easily undone. Laziness in action, but since I run almost exclusively my own sites, I get to keep all pieces myself.

    Since I don't do a lot of custom coding with WP, I usually just run updates and add plugins on the fly after taking a current snapshot. If it shatters to pieces, I restore the snapshot and usually just find another plugin to work with.

    On other projects where custom coding is abundant, I have begun to use staging environments in between beta and live. These are usually not WP sites, though. But when it comes to custom coding, I use Github for version control and pull development code to beta site for testing. When I'm happy with results in beta, it's time for staging. Staging and live environments are on the same machine and usually under the same user, so I have a simple SH script to populate staging environment by pulling current snapshot of the live environment (files and db). I then apply the beta-tested updates to staging and test it out. If all goes well, I then either run similar SH script to populate live environment from staging data (which was just pulled from live) or apply the same updates manually to live site. If everything works, I then run a script to wipe staging to avoid confusions.

    The biggest problem in this setup tends to be disparity between beta and live/staging. Since beta is populated with faux data and has a different upgrade/update history than live/staging they aren't completely similar. I occasionally run into unpredicted problems on staging that I didn't have on beta, or vice versa.

    For an external hosting provider I'd like to see at least four environments on three levels: on lowest level, one sandbox that could be easily restored to match the live site to fool around and test new things without worries, and at the same time avoid disparity of environments. On mid-level, I'd like to see two staging environments: one for longer-term testing of planned updates with some sort of logging feature to keep track of made changes, and another for the final staging (using the changelog of previous environment to apply all planned changes) before updates go live. This way you could spend some time staging new things, but also avoid losing information on busy sites. Other option would be some intelligent merging of staging to live to keep the newest entries and minimize downtime, but that could be very hard to pull off.

    I do realize that my way of organizing workflow might seem odd and that I consider staging as something that will in the end be usually just duplicated to live (and vice versa). I know there are more versatile ways to do it, but that's how I've managed so far. I'm still a recovering everything-straight-to-live type of updater.

    • Tyler Postle

      I do realize that my way of organizing workflow might seem odd and that I consider staging as something that will in the end be usually just duplicated to live (and vice versa).

      Na, more extra safe if anything :smiley: having final staging as close as possible to the live environment is def ideal I'd think. We sync our live environment to staging once a week to try and keep them as similar as we can for testing purposes.

      I'm still a recovering everything-straight-to-live type of updater.

      :joy: I like that

  • Eric Johnson

    I've only worked on my live sites with backups and snapshots to revert to if needed. I've read the cautious tales about my approach and am glad this question was asked. I now look forward to creating a workflow that can help my development process and keep my sites safer along they way.

    Right now, I host with bluehost. They provide 1 staging environment which I have not used. But I kind of like the idea of making subsites, as HawaiiDude said above, rather than the using the staging environment. I don't know which approach would be more beneficial, I'll be looking into that deeper.

    For all my updates, I've always just done them on live sites. I've not done any major updates other than the wordpress updates...I've always done them on live sites with no issues so far, lucky me.

    My sites aren't that sophisticated so I never worried about them breaking, I figured I could always restore them quickly. But, now I realize that setting up a workflow process to help protect my live sites may help alleviate stresses that I may encounter if I don't do it soon.

    I'm not sure what my ideal host provided workflow would be. But, it seems that others have at least 3 stages: Dev, Test, Live. I think I'd start with that to keep it simple and maybe add a 4th to do-dah around with if considering any design overhauls. It'd be cool to have auto change logs for each stage and also one-click up staging to move them along the flow.

    I'm still learning and really appreciate everyones participation in commenting on these topics. It really helps me find direction and discover other things that I should be considering as I develop my online businesses.

  • Matthew

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)

    Siteground - yes on premium plan.

    2a. If it does have staging, do you use it and what is your general workflow?

    I don't use the built in staging - tried many plugins to duplicate my main site with database errors (Duplicator and others).

    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes

    I used the cloning feature through cpanel softaculous found it more reliable to clone my main site to a subdomain without any errors.

    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)

    Ideally I think local environments are better as you can build a site without needing an internet connection. The downside being you can't work on it from any device (not that this would up often).

    The option to push local to a live site with the same PHP version and settings would be ideal. FlyWheel has this covered however out of my price bracket at this stage so back to the manual options outlined above.

  • Michelle

    We recently transferred to Flywheel, and I've been pretty happy with their setup. Our flow is usually using the Local by Flywheel for development, then pushing to the server when it's time for clients to review.
    We have a staging environment for each site as well, for major or time-consuming changes Example - we have a lot of restaurant sites, so updating, creating new restaurant menus can take a while and are prone to proofing errors with pricing. We'll usually send over the staging site link to one of our employees to scan for typos, wrong price, etc - before setting live.
    I am, however, guilty of updating plugins and such on the live site. Nightly backups make it quite easy to just scrap and reload...

  • splaquet

    i have a quick follow up question for y'all, which i haven't seen answered so far (and forgive me if it has already).

    question:
    migrating a website from a /dev to /live is usually a snap! but, how do you find those randomly scattered URLs that still reference the /dev URL?

    problem:
    there are a handful of plugins & themes (revolution slider & themes w/ beaver builder, respectively) that either encode the content within their own methods (hash or otherwise) or use URL encoding for characters (turning characters into code).

    solution:
    I'll build on a subdomain, or within subfolder, where possible. ...but, what's everyone's solution for when you have to transfer a website from an entirely different domain? i cannot accept that digging through each and every page as solving the problem, but i'm really not sure what other options are out there.

    does anyone have any solutions for fixing those last few broken links, that doesn't require going through each and every URL?

  • Bernard

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)
    Hi there, I use cloudways and I am very happy with their staging possibilities: you can easily copy a website to a different installation, so you can try everything you like on a backup site
    2a. If it does have staging, do you use it and what is your general workflow?
    When doing important upgrades, I try them on a second install first
    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes /
    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)
    To me it is great to have at least two staging environments and backups of both. It is great to be able to switch DNS settings to the staging environment afterwards, so you don't have to do all the copying work afterwards

  • Manuel

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)

    We/I use staging environments for websites supplied by: 1- SiteGround; 2-InMotion. Both our hosts.

    2a. If it does have staging, do you use it and what is your general workflow?

    Experiment with creation and development/build personalised/customised websites with various plugins and themes.

    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)

    For me personally a staging environment supplied by the host has been the

    best thing since slice bread.
    It has helped with the various techniques and processes of learning about all wordPress; 56,168 plugins and counting? https://wordpress.org/plugins/ ...no one will ever learn about everything WP in their life time! :thinking:
    Further on, a staging environment supplied by the host It is also about trying/testing various wpmu dev plugins and try to understand how they work, or why these don't work; try to reciprocate/follow procedures expressed by members to support in the forums and vice versa re: problems and solutions.
    Other local host i.e. xamp, mamp, ...Box are very hard to implement particularly for the initiated. Like the majority said: staging environments supplied by the hosts has other advantages, some allowing for the unlimited sub-domains, one-click backups and staging areas for individual sites/sub-sites created.

  • De Coder

    My own servers (cPanel) do not provide this, but one of my clients is strictly WP Engine, and I do a lot of "onboarding" (audit+tuneup) for his clients.

    When working on customer onboarding, I'll create a quick staging, then in the staging enable everything in cache (or try a different cache package) then compare pages to the live site, to see if anything has broken.

    Then update all plugins (etc) in the staging, and test again.

    If all this looks good, I'll make a new copy to staging, and do all this again, manually, on the live site.

    So it not only works well as intended, a place to test changes, but it's also a great quick and dirty backup, for making changes to the live site.

    I'm sure there is more I could be doing, and I really wish cPanel provided a good way to do this. (hmmm... cPanel plugin idea?)

  • Joseph Heinzman

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)
    1.We have never used a staging environment with any host we have had. Our main host(namecheap) doesn't provide a staging environment. Our others that we have used 1 and 1, go daddy, and bluehost all offered it but we never used it ourselves.
    2a. If it does have staging, do you use it and what is your general workflow?
    2a. We have our own word press development site that all our beginning development and staging is done on.
    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes.
    2b. Backup to server, backup to local, backup to hard drive. Biggest changes first and then slowly go through and get all the tweaks and on page seo taken care of. Run the back end checks make sure everything is as it should be one last time before going live.
    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)
    3. We have never used a staging environment with any host we have had.
    a.That being said, unlimited environments is always something to offer
    b.The ability to have SSL provided,
    c. Password protected directory,
    d. Multi level access admin and guest accounts.
    e. The ability to measure on page SEO without having to be connected over to google analytics.
    f. Rapid cloning where it goes into a gzip and can be reinflated and reinstalled onto any domain.
    g. The ability to use .svg files as logos out of the box
    h. Already have minification for css, JavaScript, html, ect.
    i. Being able to alter the powered by wordpress in the staging environment
    j. The ability to export the sites pages as a watermarked pdf with custom watermark capabilities.

  • Julian

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)

    Unfortunately, my host doesn't offer a staging environment. I wish they did though. I'd definitely use it.

    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes

    All changes are made on a local install and then uploaded/replicated on the live site. I should start using a staging environment because then I could see how my changes affect the site in the real environment. The local dev environment isn't configured the same as the live site's server.

    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)

    My ideal setup would be local development, then staging and then live. Preferably one click staging setup and migration from local to staging to live. As few manual steps as possible. Everything automated as much as possible.

  • Ante

    1. Who is your host(optional) and does your plan provide a staging environment? (more than 1?)

    I'm using SiteGround and their GrowBig (mid-priced) hosting package. Staging environment is not included in this package level.

    2a. If it does have staging, do you use it and what is your general workflow?

    Siteground offers staging in the highest priced package - GoGeek.

    2b. If you don’t use host provided staging, what is your development workflow for making changes to your site? Especially the major changes

    I've used MAMP and Local by Flywheel, but my laptop low performance that any flow becomes awkward. That's why I tend to create staging environment on my host. I create a subfolder on my domain and build the site there. My current clients don't have websites yet, so the flow is simple. I will set up a domain name, host it on my hosting account and, once I'm done with it, I will migrate it from my staging environment (subfolder) to production. For the new clients who already have websites, I'm planning to use similar approach and migrate the site from a subfolder/subdomain on my or their domain to production.

    3. Describe your ideal Host provided development workflow. ie. how many environments, what options would you like? More detail the better (+3 Bonus Hero Points)

    My ideal workflow would be to use staging that comes with SiteGround's most expensive package GoGeek where it's very easy to push the site to the live environment.
    My next ideal workflow would be to use Flywheel's hosting. In this case, I would build the site locally, using Local by Flywheel, and push it live with a click of a button. :slight_smile:

  • Ryan

    We're in a similar boat. We have SaaS products where on production we are dealing with 100k+ users. In our dev environments we have dummy data. So when we have to push data, we first have to clone our production over to our staging and then try to replicate the dev environment features we want pushed. For the past few months, we have looked at almost all of the different testing and staging environment. GIT is a great solution for files (themes/plugins) but not a great solution for database merger since in wordpress when you remove a plugin, not all the database entries get cleaned out. Also when merging to production, we don't simply want to override the users information. We want to merge new entries in there. We also tried bunch of hosting providers who provide "staging" environments. Unfortunately, they simply override data, not really merge.

    Definitely following this topic as it's something we all have been working and looking towards.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.