NOTICE: We've Moved to a Ticket System for Support
As of August 31, 2017 (12am EST) our support forums will be retired (read-only), and we will be moving to a support ticket system. This will allow us to better organize and answer support requests, and provide a more personalized experience as we assist our customers.
For the time being, we will leave our forums open for reading and learning while we work on creating a more robust Knowledge Base for everyone to use.
If you are a WC Vendors Pro customer please open a support ticket here. If you are a WC Vendors user please open a support ticket on the Wordpress.org forums.
The information on this forum is outdated and in most instances no longer relevant. Please be sure to check our documentation for the most up to date information.
Thank you to all of our customers!
- This topic has 4 replies, 3 voices, and was last updated 8 years, 5 months ago by
.
-
Posts
-
WC Vendor staff, feel free to delete this if it’s not fitting.
I’ve noticed a lot of people in the forums reporting issues they’ve found with the plugin, in production environments. The Product Manager and Developer in me just cringes when I read these. As a small company ourselves, I 100% understand how issues arise even after the dev team has tested it prior to release. It happens.
People, I strongly recommend before applying updates of any kind to test them on a local or development instance before pushing it to production. You’re going to save yourself from a lot of stress. There are a lot of moving parts in the WP ecosystem that can impact <b>any</b> plugin. Always test before you deploy.
Best,
-drewHi Drew,
You bring up a good point. What we will be doing, instead, is adding a “released candidate” for download, in which you can try out what we believe to be a release candidate for major version updates. For bug fixes, not so, since they are generally small things not big features. Then, if we dont get any reports of problems with a release candidate, push it to the live version. This will allow you to test, and report back anything weird you see. 🙂
Cheers
Ben
Ben, that’s great to hear. I love breaking my dev machine so looking forward to helping out where I/we can.
-dg
Drew, cracking post, but whats the best way to set up the dev site and pushes of updates even better. been wanting to set up a dev site with changes pushed over once tested, for ages, just kinda get lost in it all.
we are currently awaiting a separate server before setting ours up, always done everything live at silly hrs. i know i know very bad, but tbf im sure its how i learned most of what i know.
There are several ways to do it and it really depends on what tools and preferences you have. For us, we’re using AWS to manage these different environments. We then use a combination of tools to deploy code to each of these environments.
For our dev environment, code is automatically deployed anytime someone checks code into the default branch. We do this with the help of Mercurial and Jenkins. There’s a plugin available for GitHub. We just choose to store our source code on our own servers. Our main dev environment is always online due to the abuse we throw at it. We do have other dev environments mapped to different branches and projects, but those are only running as needed. Typically for demo reasons or if we have multiple big projects going on.
Once we think code is stable enough we boot up our staging environment and deploy the code using Jenkins. Our staging environment is a scaled down version of our production setup (ELB, cloned prod data, etc.). This allows us to make sure we don’t run into anything unexpected when we do push to production.
Jenkins is then again used to promote the code to production servers. Users don’t notice anything for the most part. However, I typically deploy updates during non-peak hours and I’m always sure to check with the marketing team and their schedule.
In summary: AWS + Source Control + Automated Builds & Deployments
Ps. There’s a lot more that goes into some of this. Configurations for our website and api are modified based on which environment the code is being promoted to. For instance: email notifications are disabled on non-production servers, we make sure google isn’t indexing content on these servers, etc. I only mention this so you keep this in mind when creating your own plan.
- The forum ‘WC Vendors Pro Support’ is closed to new topics and replies.