Vulnerability in EPiServer.Forms

Try our conversational search powered by Generative AI!

Darren Stahlhut
Apr 1, 2019
  1961
(3 votes)

GitFlow is a natural fit for Episerver DXC

In this blog, I'll explain a little about GitFlow and why it aligns so well with Episerver DXC development.

What is GitFlow?

If you're not familiar with GitFlow, it's just another branching and merging strategy. It was made popular by Vincent Driessen at nvie and has since been widely adopted by the development community.

It's also built into the most popular Git Clients including SourceTree and GitKraken and is available via commands in Git console.

What I like most about GitFlow, is not the merging strategy itself, but its things that having a standard strategy offers;

  • We can more easily collaborate with external developers and Agencies. We can simply by say "we use GitFlow" and they'll know what we mean.
  • Onboarding Developers is faster, there are a lot of good learning resources around.

GitFlow merging strategy (in a nutshell)

There are two main branches in GitFlow;

  • master - the code you have or are going to release.
  • develop branch - the latest development, changes for the next release.

Besides the main branches, we also have;

  • feature branches - this is where you actually do your development and commits.
  • release branches - a branch to get code ready to release to master.
  • hotfixes - for emergency fixes for master branch to be immediately released.

GitFlow merging diagram

Why does this work well with Episerver DXC?

Because of Episerver DXC's linear deployment path, code must be deployed from Integration > Preproduction > Production.

This means we can think of our Master branch as the code ready to be deployed to Integration.

Deployments above Integration are managed via the Paas Portal or via Episerver Support.

If you also want to have an internal CI/CR (build and release) environment for internal QA, you can run it off the Develop branch

This all means we can use the standard implementation of GitFlow.

Wrapping it up

I'm not saying GitFlow is perfect, but it is a decent merging strategy. It can become complicated when you aren't certain about the order that Features will be released and I have some very large scale projects that GitFlow struggles to handle so we have a customized strategy.

But generally speaking, for Episerver DXC projects where the deployment chain is linear, I've found it's a great fit.

This might change in the future if we are allowed to use our own DevOps tools to deploy directly to Preproduction (or even Production) which is something I've heard is on the technical roadmap. 

Resources

Apr 01, 2019

Comments

Marcus B
Marcus B Apr 1, 2019 02:42 AM

We will be enabling more options for devops in the DXC Service this year too, so hopefully it will meet everyone's preferences (i.e. not just GitFlow) in the future too :-)

KennyG
KennyG Apr 1, 2019 01:32 PM

I'd really like to be able to grab a bacpac of the Prod database from the Paas portal. Good to hear there are some enhancements on the horizon.

Apr 2, 2019 08:44 AM

We've been using GitFlow for quite a few years and it's good in a lot of situations. To note there's a great VS 2017 extension as well https://marketplace.visualstudio.com/items?itemName=vs-publisher-57624.GitFlowforVisualStudio2017 if you don't want to leave the VS workflow.

We do have problems as a digital agency running multiple projects and support work in parallel. Therefore we double branch, e.g. we have a feature branch for project and then sub-features for work items. This allows us to make sure develop/master are only updated when projects are complex. When then create release branches off our project branch. This in our expereince has allowed reduction in overlap or issues and the ability to deploy out branches in a more parallel structure.

When the DXC get's hotflix deployment support to be able to deploy direct thing like this will be even more important.

Apr 2, 2019 10:37 AM

@scott awesome, sounds like we are basically running our strategy the same way.

We do most of our commits on feature/sub-feature branches, then submit PRs from sub-feature to our  feature branch. When its time to release the feature, we create our release branch. 

We internally host an Episerver instance as the CI/CD target for the develop branch. Sometimes we use this to test release branches prior to merging to develop. I've often thought of scripting up infrastructure as a service to test our release branches.

Please login to comment.
Latest blogs
Google Read Aloud Reload Problems

Inclusive web experiences greatly benefit from accessibility features such as Google Read Aloud. This tool, which converts text into speech, enable...

Luc Gosso (MVP) | Dec 4, 2023 | Syndicated blog

Google Read Aloud Reload Problems

Inclusive web experiences greatly benefit from accessibility features such as Google Read Aloud. This tool, which converts text into speech, enable...

Luc Gosso (MVP) | Dec 4, 2023 | Syndicated blog

Import Blobs and Databases to Integration Environments

In this blog, we are going to explore some new extensions to the Deployment API in DXP Cloud Services, specifically the ability to import databases...

Elias Lundmark | Dec 4, 2023

Join the Work Smarter Webinar: Working with the Power of Configured Commerce (B2B) Customer Segmentation December 7th

Join this webinar and learn about customer segmentation – how to best utilize it, how to use personalization to differentiate segmentation and how...

Karen McDougall | Dec 1, 2023

Getting Started with Optimizely SaaS Core and Next.js Integration: Creating Content Pages

The blog post discusses the creation of additional page types with Next.js and Optimizely SaaS Core. It provides a step-by-step guide on how to...

Francisco Quintanilla | Dec 1, 2023 | Syndicated blog

Stop Managing Humans in Your CMS

Too many times, a content management system becomes a people management system. Meaning, an organization uses the CMS to manage all the information...

Deane Barker | Nov 30, 2023