Shared Private Repository
Our Enterprise plans come with the option to open a private code repository that you share with the Vanilla Forums team on GitHub. This allows your developers to view and contribute to your customizations.
Setup
Your Customer Success Manager will provide you with this repository. Please allow the Vanilla team to organize its structure appropriately and name files.
We use master branch for production deploys. Anything on that branch should be ready for immediate release. The stage branch can be periodically deployed to your staging site for testing. New features can go on their own feature/x branches or on a develop branch for integration testing prior to staging.
Accounts
You will need a GitHub account for each developer that requires access. We strongly suggest limiting the number of developers on your team with direct access to the repository for workflow and communication clarity.
Local testing
If you’d like to use a local Vanilla installation for testing, please use the master branch from our main repository. Follow the installation instruction in the README.
Unfortunately, we are not able to provide cloud-exclusive addons for local installation. However, some additional addons may be found in the addons repository.
Deploy Process
Depending on how you like to work, you could choose to set up a local instance of Vanilla and work on local first before it even hits staging.
Deploy to Staging
For theming work, you can simply prepare a PR pointing at the stage branch including commits containing the changes pointed at staging and assign the PR to your CSM. If your CSM has not shared their Github username with you, please contact them. Your CSM will have a Vanilla dev review the PR and deploy to staging.
For minor CSS-only changes to stage, the review process is generally quick however if this is the first time your theme will be deployed to your staging, this will take longer and so please coordinate this with your CSM.
Deploy to Production
Once you are happy with your code on staging, prepare a PR pointing toward the master branch with your final commits. Again, have this PR assigned to your CSM and they will have a Vanilla dev review and deploy to your production site.
Commit Process
When making changes to your theme you will want to create PRs to individual branches as shown below. After creating a PR with commits to local (if necessary);
- Create a PR with commits to
develop (if available) - Create a PR with commits to
stage - Create a PR with commits to
master
Never merge stage to master.
You can read in more detail about our PR process below.
Note: This article is geared a bit more toward open source, but the core concepts remain the same.
Code Review Rates
The review of customer created code and any training that falls outside of the normal onboarding process will now be billable according to the rates outlined below.
Supporting developers when they have questions that are not clearly addressed in the documentation, or are due to bugs, will continue to be included as part of our service on the Corporate and Enterprise (formerly VIP) plans. These new rates do not apply to customers who have existing service rates specified in their customer agreements.
*Hourly rates for code reviews will be billed in 10 minute increments and invoiced monthly if 60 minutes or more has been consumed since the previous invoice.
