Is there a guide or best practice manual for using Oxide in a multi-developer environment.
We recently started collaborating on one of our apps and have been a bit frustrated with what appears to be developers working against each other.
In some cases when I for example commit my code another user isn’t prompted to pull the changes. This is just one of a couple of challenges.
We are likely doing something wrong on a fundamental level.
@matthew Are you using Advanced (Git) mode or Basic (Revisions) mode?
Thank you for your response.
My assumption was always that we are using Advanced (Git) Mode (refer screenshot below).
You should expect to see the “Pull changes” button if there is any commit ahead of your branch. In other words:
- you are busy with your draft and another developer commits on that same branch
- you are busy with your draft and someone merges in changes into your branch
If this is not the case, please send a support ticket to email@example.com so we can investigate.
Guide on how multiple developers can effectively work together:
Advanced (Git) Mode:
You should have the ability to create different branches. In OXIDE, you can open the command palette, find the “Create branch” action and follow the prompts.
A structure that works well for us is to always have the following three branches:
The purpose of each branch is:
This is where all the development takes place. Good practice for when a developer needs to implement any changes, is to create a new branch from this
develop branch, implement the necessary changes on the new branch and then merge it back into this
develop branch. The new branch can be deleted if the developer is done with it to keep the list of branches clean.
Temporary branches like these can be created for new features, bug fixes, hot fixes, etc. Good naming convention examples are:
Following these guidelines, I can work on my own branch when I need to make any changes without being worried about other developers’ changes. All changes implemented by different developers get merged into the
develop branch in the end.
develop branch should be deployed to a Testing Database which is a safe environment for developers to create test data when testing new features.
Please see the JourneyApps Documentation for more information on how to configure Testing Deployments.
develop branch can be merged into this
release branch for any User Acceptance Testing (UAT) that needs to take place before releasing changes to Production. Usually a small group of end users will test the newly implemented changes and provide feedback. Any changes that developers should implement based on the end users’ feedback should be implemented as described in the first point. Those changes can then be merged into this
release branch again. This cycle can be repeated until developers and the User Acceptance Testers are ready to deploy the changes to Production.
This branch should be deployed to a Staging Database that will be used by whoever takes part in the UAT process.
This branch contains the final product that will be used by all end users of the app. The
release branch can be merged into this
master branch when everything has been tested thoroughly and if it is ready for Production.
Only this branch should be deployed to the Production database which contains the real-world data.
Note on hot fixes:
Hotfixes can be implemented on the
master branch when a bug occurs that needs to be fixed urgently. In these cases a branch can be created from the
master branch where the fix can be implemented and then merged back into the
master branch again. You should remember to pull this fix into the
develop branch as well to ensure that they also contain the fix.
If you are using revisions mode in OXIDE, you will not be able to create multiple branches. In this case it is important to:
- Make sure the auto-deploy setting is switched off to avoid constant deploys from different sources.
- Ensure that there is good communication between the developers.
- Pull other developers’ changes into your draft to ensure that you have the latest changes.
- Give co developers a heads-up before you deploy anything.
I hope this is helpful