How do you feature branch when running a UaaS project and want to share code with developers, BUT don't want it be comitted to the development branch? Maybe you have a feature that needs 3 weeks work, but you push minor bug fixes to the site every week from development to staging to live.
A UaaS project consists of a Development and a Live environment (some projects might also have a Staging environment, but Development+Live is the default). Each of these environments has a git repository used for deploying the site. This is just a regular git repository, so it can be used as any other git repository. The only thing to note is that its only ever the "master" branch that is deployed between environments. What this means is that when you click the deploy button on a project in the UaaS Portal the "master" branch is pushed to the next environment. Its not currently possible to change the default branch for any of the environments in a project.
From your locally cloned git repository you can branch off "master" and create a new branch called "feature-branch-x" and you can push this to the remote, which is the development environment in your UaaS Project. Any other developers with access to that Project can then pull that branch down. But please note that its only ever the "master" branch that is deployed to the website in the development environment.
With regards to your question, you can branch off "master" and work on that new branch (locally and push to share with others). For bug fixes you would commit your changes to the "master" branch. Those fixes can be merged into your other new branch - keeping your feature branch up to date.
Now, I don't know how complex your process around bug fixes is, but the easy approach is to use the "master" branch and the development environment for testing/verifying the fix and deploying to the next environment (staging or live) when its ready to be rolled out.
Each develop runs a local instance of the website and we use a shared database and shared media.
We have a internal test environment where we deploy our finished features too. This environment has a it's own db.
We have a staging environment where we deploy our releases too when all features have been tested internally and are ready for testing by the customer
We have a live environment. Here releases are pushed too when tested by customer on staging
Our branching model is the following. We have one git repository for the website with the following branches
- develop (local environments)
- qa (test environment)
- staging (staging environment)
- master (live environment)
So in a typical project develop and qa (and sometimes staging for a short period) are ahead of master.
So in case we need to do a hotfix on live we create a branch from master and fix the issue locally. If the issue is fixed we merge it into staging so the customer can test it. After approval we merge the fix in to all other branches and do the push to the live environment.
How can we handle this flow with Umbraco Cloud ? Because the difference there is that each environment has it's own git repository.
I just tried to do this. By making a small change on live (so called hotfix). But this get's overwritten as soon as I push from dev to live ?
For our own code that is in our own git repository this is not a problem.
But it's things that are in the deployment repository (templates and other views, doctypes)
So the basic question is how do we get changes made on the live environment in to our dev environment ?
Nope, it's the same one. Or yes, technically, each .git folder anywhere in the world is a "unique" git repository. But if you can push to a git repository without using --force then it's "the same" repo (as in: they must be very strongly related).
The problem here is that Umbraco Cloud (UaaS) knows nothing about your branches. So whatever you push in master is what gets deployed througout your environments. You can work in branches locally, then you can branch off of master, fix the bug, have another developer test it. But then you will need to merge back into master to deploy this fix.
The only way to really do this right now is a hack but it should work:
Make a branch of off the commit that is currently live on your site (let's say it's called bugfix)
Rename the master branch to something else (yes, this is possible) like temp-master
Rename your bugfix branch to master
Fix the bug
Push to UCloud
test, etc. and eventually push all the way to live
Once this is all accepted you can rename master back to bugfix and temp-master back to master
Finally you can merge bugfix into master and eventually push that when you're ready working on whatever you're working on
Caveat: I've never tried this, but in theory this should work.
I think you misunderstood what I'm trying to explain...or I explained it badly.
Let's try to explain it without the branching model we use now.
So our site is live and on develop is ahead because we are working on the next release of the website. The changes on develop can not be pushed to live.
But now the customer finds a critical bug on live that we need to fix ASAP.
How can we do this without deploy changes from dev to live ?
I have been thinking of another possible approach. Would like to hear any comments.
Say I have two environments (live and dev). On dev, I have a huge ongoing task, not ready for deployment, and now I need to do some changes to live.
Locally, I have added both the dev repo and live repo as remotes for my project.
I then check out live/master, and make a new branch, let's just call it "some-new-feature". I do my changes, maybe involving schema updates etc, test it locally and are then ready to get it signed off by the client.
I then merge my "some-new-feature" branch into dev/master and push, so my new feature gets deployed to dev. Client tests, signs off and now I need to get it to live. I can't deploy from the portal, because that would deploy the unapproved task mentioned earlier, so I merge "some-new-feature" into live/master and push.
If I get it right, it would deploy only the changes in "some-new-feature" to live, and everything would be all ok, right? And when my huge task on dev is signed off, and deployed to live, git will know that "some-new-feature" already is in live/master, and just let it be, right?
Only downside is, that if I have any dll's or minified css/js in "some-new-feature", then that would probably end up in a merge conflict some time. But working through git all along, instead of the portal would let me handle those conflicts in a timely manner, right?
Feature branch in UaaS
How do you feature branch when running a UaaS project and want to share code with developers, BUT don't want it be comitted to the development branch? Maybe you have a feature that needs 3 weeks work, but you push minor bug fixes to the site every week from development to staging to live.
Kind regards
Anders
I'll try to clarify here:
A UaaS project consists of a Development and a Live environment (some projects might also have a Staging environment, but Development+Live is the default). Each of these environments has a git repository used for deploying the site. This is just a regular git repository, so it can be used as any other git repository. The only thing to note is that its only ever the "master" branch that is deployed between environments. What this means is that when you click the deploy button on a project in the UaaS Portal the "master" branch is pushed to the next environment. Its not currently possible to change the default branch for any of the environments in a project.
From your locally cloned git repository you can branch off "master" and create a new branch called "feature-branch-x" and you can push this to the remote, which is the development environment in your UaaS Project. Any other developers with access to that Project can then pull that branch down. But please note that its only ever the "master" branch that is deployed to the website in the development environment.
With regards to your question, you can branch off "master" and work on that new branch (locally and push to share with others). For bug fixes you would commit your changes to the "master" branch. Those fixes can be merged into your other new branch - keeping your feature branch up to date.
Now, I don't know how complex your process around bug fixes is, but the easy approach is to use the "master" branch and the development environment for testing/verifying the fix and deploying to the next environment (staging or live) when its ready to be rolled out.
I would recommend reading up on 'gitflow': http://nvie.com/posts/a-successful-git-branching-model/
Hope this helps,
Morten
Hi Morten,
I have some additional questions on this.
Let me first explain how we work normally.
We have this setup.
Our branching model is the following. We have one git repository for the website with the following branches - develop (local environments) - qa (test environment) - staging (staging environment) - master (live environment)
So in a typical project develop and qa (and sometimes staging for a short period) are ahead of master.
So in case we need to do a hotfix on live we create a branch from master and fix the issue locally. If the issue is fixed we merge it into staging so the customer can test it. After approval we merge the fix in to all other branches and do the push to the live environment.
How can we handle this flow with Umbraco Cloud ? Because the difference there is that each environment has it's own git repository.
I just tried to do this. By making a small change on live (so called hotfix). But this get's overwritten as soon as I push from dev to live ?
For our own code that is in our own git repository this is not a problem.
But it's things that are in the deployment repository (templates and other views, doctypes)
So the basic question is how do we get changes made on the live environment in to our dev environment ?
Dave
Nope, it's the same one. Or yes, technically, each
.gitfolder anywhere in the world is a "unique" git repository. But if you can push to a git repository without using--forcethen it's "the same" repo (as in: they must be very strongly related).The problem here is that Umbraco Cloud (UaaS) knows nothing about your branches. So whatever you push in master is what gets deployed througout your environments. You can work in branches locally, then you can branch off of master, fix the bug, have another developer test it. But then you will need to merge back into master to deploy this fix.
The only way to really do this right now is a hack but it should work:
bugfix)masterbranch to something else (yes, this is possible) liketemp-masterbugfixbranch tomasterbugfixandtemp-masterback tomasterbugfixintomasterand eventually push that when you're ready working on whatever you're working onCaveat: I've never tried this, but in theory this should work.
Hi Sebastiaan,
I think you misunderstood what I'm trying to explain...or I explained it badly.
Let's try to explain it without the branching model we use now.
So our site is live and on develop is ahead because we are working on the next release of the website. The changes on develop can not be pushed to live.
But now the customer finds a critical bug on live that we need to fix ASAP.
How can we do this without deploy changes from dev to live ?
Dave
Yep. So in short:
Yes, you will revert your changes on dev for a while until you rename the master back from
temp-mastertomasterand push it again.I get it now.
So basicly you swap your current dev(/staging) with the fixed version of live. And when bugfix is rolled out. You swamp them back.
This will require some fast testing from customer end then.
And good coordination between developers on branch usage while bugfix is in testing.
Dave
Indeed.. :) Told you it wasn't a great story at the moment.
In the future we obviously want to make this heaps easier and support branch selection when deploying!
(and no, we don't have a timeline for that yet :-) )
Hi Sebastiaan,
Any news on the ability to deploy feature branches to an environment? Would be a great feature :)
Thanks,
Stephen
GREAT reply Morten! Glad it works just like a normal git repo
Kind regards
Anders
Hi all
I have been thinking of another possible approach. Would like to hear any comments.
Say I have two environments (live and dev). On dev, I have a huge ongoing task, not ready for deployment, and now I need to do some changes to live.
Locally, I have added both the dev repo and live repo as remotes for my project.
I then check out live/master, and make a new branch, let's just call it "some-new-feature". I do my changes, maybe involving schema updates etc, test it locally and are then ready to get it signed off by the client.
I then merge my "some-new-feature" branch into dev/master and push, so my new feature gets deployed to dev. Client tests, signs off and now I need to get it to live. I can't deploy from the portal, because that would deploy the unapproved task mentioned earlier, so I merge "some-new-feature" into live/master and push.
If I get it right, it would deploy only the changes in "some-new-feature" to live, and everything would be all ok, right? And when my huge task on dev is signed off, and deployed to live, git will know that "some-new-feature" already is in live/master, and just let it be, right?
Only downside is, that if I have any dll's or minified css/js in "some-new-feature", then that would probably end up in a merge conflict some time. But working through git all along, instead of the portal would let me handle those conflicts in a timely manner, right?
Curious to hear what you guys think.
is working on a reply...