Best Practice - Multideveloper Environment

Guides
1

Dear All

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.

Best regards
Matthew

2

@matthew Are you using Advanced (Git) mode or Basic (Revisions) mode?

3

Hi Tielman

Thank you for your response.

My assumption was always that we are using Advanced (Git) Mode (refer screenshot below).

image

4

Hi @matthew

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 support@journeyapps.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.

    image
    image1408×520 49.8 KB

    A structure that works well for us is to always have the following three branches:

    1. develop
    2. release
    3. master

    The purpose of each branch is:

    1. develop:
    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:

    • feature/new_admin_page
    • hotfix/cannot_submit_data

    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.

    The 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.

    2. release:
    The 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.

    3. master:
    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 release and develop branch as well to ensure that they also contain the fix.

  • Revisions Mode:

    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 :slight_smile:

1 Like