Please help me understand on the below
What is the release process that is practiced in general(standard practice)?
Can we do a release from branch?
How can we merge the code from branch to trunk, if we have to do a release only from branch(is there any plugin for this)?
Vijay
Standard release practice :
Every Software delivery is based on a SDLC model ( waterfall , V or Agile...) which have different phases and the common onces are :
1.Requirement Analysis
2.Design (High level design document and Low level design document)
3.Code
4.Test
5.Deploy
6.Release to end customer
To manage a release various practices are followed to ensure that the end-product should be exactly similar to the requirements.
During a release :
1. Release notes
2. Release Matrix has been maintained to keep track of what is going in which release and which release version has been deployed to which environment .
Once the design , code , testing gets completed on getting a final go-ahead the product is tagged and released to end customer .
If any changes comes work will start on Minor release , for critical issues hotfix is used to be dispatched .
Best Practices as per my understanding :
1. Decide a proper model for the particular release according to end customer requirement.
2. Namimg convention shld be properly decided .
3. Release notes should be provided with each release and must be reviewed .
A Software product can be released from branch once it is tested and tagged .
In Subversion there is concept of release branch as well. "http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html"
Merging branch back to trunk is called as branching back to trunk
You can follow the below mentioned steps:
Update the branch working copy and merge all the changes from trunk first into the branch.
Now the branch is in sync with trunk .
Checkout working copy of trunk and merge branch to trunk .
Make sure there must be no locally modified file before you perform merge :
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html
Regards
Jyotsna
Related
Doing trunk based development to achieve continuous deployment. And this is our branching strategy.
master > whats live in production
release > test passed and release point created by CI server
dev > daily merges from the development team.
If we consider doing the pull request from release to master stage.
What are the pros and cons to that approach? How can we communicate this with the development team where they want to do PR at dev branch?
I don't really have an answer, but think the context of the question is worth further discussion.
If you're doing Continuous Deployment, then I'm not sure of the purpose of the Release branch. It seems to be duplicating the purpose of either:
'master': code being deployed/released
'develop' integrated feature
branches, but not ready release
Or, are you using it to group milestones or planned major releases (i.e. Release/1.0, Release/2.0), like a mini-master branch.
I would not consider this Continuous Delivery (deployment, maybe), but it is certainly a valid pattern if your project requires staged releases rather than Continuous Delivery.
It's also important to also consider your CI setup and how it integrates with your branches. It isn't source code that is deployed to Production, but the build artifacts from your CI system. Thinking about this might simplify your branching model.
If you want to rollback, you don't want to rebuild the application from source, you want to re-deploy the pre-built artifacts of the previous version. Likewise, if you have a build that has passed all your tests and is ready to ship - hopefully is already running on your pre-production environments - you don't want to merge it to a different branch, rebuild it and then deploy the new build - you use the build that was tested.
The next consideration is that every additional branch adds time & complexity for the developers. Merging, pull requests, waiting for CI to run, etc. are not free so reducing the complexity of the branching strategy to the minimum you require is a good goal.
To answer your question about where to PR to/from, do you consider "Develop" as the mainline and attempt to keep it stable and working at all times?
If so, then the PRs from feature-to-develop are the key integration. Develop is then built, tested, and deployed to your test environments.
Branching from develop at that point (i.e. to create a Release branch) is then known to be good.
Promoting that artifact from your test environment to production, without re-building, might remove the need for one of your branches.
I am very new to Team Foundation Services(free by MS). I have created this structure of my source code and it served well so far.
My source code structure
I want to understand how to create various branches so that when I do a major release on production I can separate & secure the source code so far in a branch, create a new branch and start working on it for next phase . Something like
Fit***
Phase 1
Phase 2
Phase 2
Thanks in advance.
If you are using TFVC as your source control. There are built-in branching and merging features in TFS. You can achieve this from GUI directly or use Team Foundation version control commands . More detail info you from MSDN for your reference: Use branches to isolate risk in Team Foundation Version Control
If you are using GIT as your souce control, it's the same. You can use Git command and you can also create it in Team Explorer by following this: Create work in branches
If you meaning you just want to choose a branching strategy for releases. You can
Option A. Just using mainline and tagging for release
Option B. Branch
by release
Option C. Crazy Bonus Option
Details, please refer the answer from Keith Brings in this question: Choosing the right branching strategy for releases
When I was using
mvn jgitflow:release-finish
I noticed that the release branch got merged into master branch.
Question: Is this the correct way?
Sorry my questions might be naive as I am new to this. I was thinking that the code from release branch will merge to develop and master and not like release --> master --> develop.
Question: What if I don't want this to happen and instead I should be in a position to rebase develop from master?
When I was using mvn jgitflow:release-finish I noticed that the release branch got merged into master branch. Is this the correct way?
This is the correct way according to the main philosophy behind, gitflow:
Release branches
May branch off from:develop
Must merge back into: develop and master
And according to the plugin documentation, the release-finish indeed merges back to the master and dev branch:
finishing a release - runs a maven build (deploy or install), merges the release branch, updates pom(s) with development versions
This makes sense, because (again back to gitflow):
When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.
I was thinking that the code from release branch will merge to develop and master and not like release --> master --> develop.
The order follows this flow (first master, then develop) because it's a release and as a release it must firstly go to master (which should always represent the released code base), then to develop (whish is the next potential release code base).
What if I don't want this to happen and instead I should be in a position to rebase develop from master.
You can use the noReleaseMerge option:
Whether to turn off merging changes from the release branch to master and develop
Default value is to false, hence by default merges are performed. However, the option covers the two merges, you cannot disable only one of them, it's either both (again, following gitflow philosophy) or none. This option may suit your needs but you would then perform additional actions via git commands.
I'm trying to put in place a way to permit to developers to be able to sometimes apply a patch on an already delivered version of an application.
before any delivery to a pre-production env we've to release our app.
code versioning system is CVS
here's the use case :
date 1 : we release the application (with maven) which will be deployed on the server (webapp)
date 2 : on (head) there had been commits
date 3 : a bug appears on the pre-production env and we've to deliver a patch, the problem is that we already committed some unfinished features they must not appear on the pre-production env.
I proposed to checkout the code from the already released version (the one of date 1), make the fix and then release from that version.
My question : Is it possible? what will happen to head?
You can do it as follow :
Suppose that the your tag is 1.0
1 - create a new branch (named for example 1.0-hotfix) from the tag of release (1.0 )
2 - checkout the new branch in another local directory
3 - Make changes to your source, commit and release !
4 - finally merge the branch into HEAD
For maintenance and patches you need to be able to work on parallel versions. Usually this is done with the concept of branches, cvs support this feature.
Maintenance branch are very common to apply patch to older versions.
Nothing will happen to head.
While cvs or svn support branches, the implementation in DVCS such as git is much better. Switching to a DVCS would save you a lot of time in the long run.
How do you handle versioning in a continuous integration environment where there is a development branch and a release branch? I'm using git so there is no incrementing repository version to use. Seems like there will be overlapping versions such as 1.1.0 on the dev branch and 1.1.0 on the release branch. Do you just append the text "dev" or "release"?
Also, when you create a release branch do you immediately increment the development branch to the next "proposed" release number? You may not know the next release number yet but if you don't increment it then you have 1.1.0 dev containing new work not included in 1.1.0 release.
So my main question is what is the relationship in the versioning sequences between these two branches?
Keep in mind, I'm not asking anything about how to decide what version numbers to use. I tried asking this before and kept getting comments like "increment major for breaking changes" etc.
I don't version the dev branch. The devline is the trunk and I periodically branch from dev to a new release folder. So the release branch is full of folders which are basically snapshots of the devline.
IE, under root I have /dev, /releases/0.1, /releases/0.2, /releases/1.0, etc.
I'm not sure if this really answers your question.
I would recommend set a final activity for your CI environment to make tags. I believe the git command looks like this: git tag -a name
We use Major.Minor.Release.BuildNumber
though some places use Major.Minor.Release.CheckinNumber
So, if you want to use that then I would version your dev branch, otherwise just version the release branch.
If you have only one development branch, it is more effective to make it be the trunk and branch off a release branch every time you just want to stabilize for release. If you have multiple feature projects, you can have a branch for each of them with CI setup on those. Once they are done, you merge them one by one to the trunk and once all are merged, you get to the first scenario, where you branch a release branch off of the trunk again.
In any case, you don't keep the development branch going between releases. You want to end it and start a new one for development for the next version. This way some of the features can be branched off during several releases if they take longer. But also you don't have too much mess on your development branches.
You can branch the development branches for the next version as soon as you branched the release branch or even before if you chose to, but it is generally good idea once you stabilize for release, merge the changes from release branch into trunk and from there into the development branches if you do that. If you wait with branching off after release, you avoid few merges there, but you slow down development.