Architect – Our Website Branching Strategy @ Marie Curie Cancer Care

What we use

We use a combination of Git, EPiServer and have a fairly small team which makes the challenge of using the standard pattern of Gitflow a little more difficult. So we use a part of it to help us get an excellent balance between being responsive to post production issues and minimal branch maintenance.

Challenges

Due to EPiServer controlling it’s Dynamic Data Store via code, we have to be a little more careful when switching branches on a given environment. This is because EPiServer will hide or show properties depending on what is reflected in the latest code. This could lead to impacting someone else’s work.

We do currently experience this in the Develop environment where one developer may have a code base with a deleted or renamed property. This will cause an issue with another developer who has the original property definition. So both sets of code bases will be fighting each other to set that property on the database which results in some exception behaviour when running the website.

An old colleague James Goldswain messaged me with this:

Check out the enableModelSyncCommit=”true” setting in the Episerver.config file, it enables you to disable the auto updating of properties etc, when developing in a team, found it out the hard way ūüôā

We have a limited number of environments due to resources and set up time. In an ideal world we would have a new environment spin up from either a feature or hot fix branch so QA can test in isolation from everything and everyone else.

We cannot deploy hot fix or feature branches to the QA environment because that will create blockers for other members of QA. Our QA environments require all testable features to be merged to the develop branch first before deployment.

Strategy

We adjust our branch strategy from Gitflow so we:

  • Do not block any member of the scrum team from working on any environment.
  • Make the effort to keep feature and hotfix branches as short as possible in order to avoid developer going dark
  • Sync both Master and Develop branches at the end of every sprint to ensure everything is up to date. If we are going Gitflow correctly then we shouldn’t need this. (There is an occasionally extra merge commit that moves from Master to Develop due to hotfixes)
  • Feature and hotfix branches get merged as soon as possible to minimise timeline regression.
  • QA and UAT never test¬†on¬†feature or hotfix branches, only Develop and Master.
  • Our team is small enough to warrant not using the release branch workflow as¬†we¬†rarely get any issues with unfinished work at the end of the sprint.

We have four types of branches we use. The Master and Develop branches are static. Hotfix and features branches can be created any number of times and typically have short life spans before being dumped or merged into one of the static branches.

Master branch

According to Gitflow this branch represents our production ready code. We should be able to push code from this branch into production at any time.

However due to our challenges, we also use this branch to deploy to both Staging and Production. This effectively makes it our UAT and Release environments. We push to Production at the end of every sprint and also when hot fixes are merged in.

Develop branch

This is the bucket branch for any development changes that are not post production issues and not significant enough to have their own feature branch.

The branch is also used for both the develop and QA environments. This allows for QA to test singular user stories and provide feedback during the sprint.

Hotfix/xxx branches

Bugs and issues discovered during post production are worked on hot fix branches created from Master. Completed hot fix branches are then moved into both Master and Develop. Once the work is approved we then delete the branch.

Feature/xxx branches

Significant features that can be worked on in isolation are done in their own branch. We create this off Develop. Good examples include a blog or a newsletter sign up. These branches are then worked on by the developers and then must be merged into Develop once they are ready for testing.

These branches¬†should only exist for the length of a sprint. If it needs to exist into the next sprint then ‘commits’ on the Develop branch is merged up into the Feature branch in order to keep it up to date.

Architect – Technical Design Workflow for Creating New Fundraising Page using JustGiving API

JustGiving provides an API that allows charities to create fundraising pages from their own website. Charities benefit from this by being able to integrate this functionality into their own user journeys.

I designed a user journey workflow for a user to create a JustGiving Fundraising Page in remembrance of someone for where I currently work.

From a technical perspective I worked on this taking into consideration the capability and limitations of the JustGiving API. This is so I could empower our UX guys with the right information in order to make the user journey as efficient at possible and not to get hindered by technical limitations later on in the process.

My initial thought was I needed to create a journey that allowed the user to take a minimum amount of actions to get to the end goal of creating a fundraising page. Anything after that could be included as an enhancement or additional requirements from the business that hold value else where.


This what I took into consideration is:

  • You require an active Just Giving account to create a fundraising page. The workflow supports users who do and do not have a pre-existing account.
  • At this point (as standard with any account functionality) the workflow it forks out and forks back in again ending up with the user¬†that¬†is logged in with an account.
  • We then describe the required fields we must expose and¬†the optionals ones that we could take advantage of.
  • Each relevant step also mentions the correct API call that is needed.

Architect - Design Workflow for Creating New Fundraising Page using JustGiving API