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.
Related
I'm currently in the process of implementing CD with a Feature Branch Workflow. What's unclear to me is when to increase the version number.
Shall it be increased when a new feature is created?
So let's say we have version 1.1 and I'm going to implement a new feature FB-123.
When creating the FB shall I increment the version?
*---*--- increment build number, now on 1.2.456
/ increment version to 1.2
---* 1.1
And use the Jenkins Build number for subsequent commits?
I would consider to use the following versioning schema:
Every major/minor release is tagged with a git tag
branches schema - <major>.<minor>.<number of commits from latest minor>-<feature branch-name>-<sha1>
master schema - <major>.<minor> (it considers that every accepted pull request is a minor release)
You can calculate the number of commits from latest minor by
git rev-list HEAD ^<latest minor tag> --ancestry-path <latest minor tag> --count
This schema will allow you to derive from the version name:
the base version
the branch name
the git commit that the version was built from
to compare properly 2 versions of the same branch
We'd like to increment the minor version of our application each time we create a new branch for release. So if, for example, the current version is 4.17 the next branch we create would automatically increment the version number to 4.18.
Our scheme is that the code follows the following path:
Dev -> Test -> Staging
so that the testing happens on code we think has the functionality required and only that code that passes testing is available for release.
Then when the time comes for a new release we take a new branch of Staging, so we have the following structure:
Staging
|----> Release 4.1
|----> Release 4.2
...
|----> Release 4.17
There is no cross pollination between the release branches.
So what we need is something that will increment the minor version number when a new branch is taken. We can reset the version number of the application in Dev/Test/Staging to anything that needed for this to work.
Is this possible with TFS/VS 2013 out of the box?
That is a bad smell!
You have to do that on one branch, and no in all... And not change the assembly number in a manual way...
The TFS Versioning could help you to do this.
In the community build tools you will find an activity called TFS Version. This tool can, in its default configuration, strip the version number from the build name. If you name your build for the branch to be mybuild_7.8.0$(.r) the tool can be configured to pick up that version and store it in a variable. You can then use that variable to update the AsemblyInfo.* file versions.
This is the correct way to do what you are asking. Do not check the changes in, and indeed set the checked in numbers to be 0.0.0.0. This way you will be able to identify when a cheeky developer has done a local push and when it came from a build server 😃
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
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
I am thinking about a deployment pipeline using SVN, Jenkins and Maven. At the moment I'm stuck at the point where I usually would call mvn release:perform on a working copy.
When thinking in deployment pipelines, I want to create a pipeline where every commit could be used to release a software to test/production. Let's say I have 5 builds, and I decide to release build 3 (with revision 3) to production. There will already be 2 new commits to trunk (which is now at revision 5).
Is it possible to use the maven-release-plugin to checkout/build/tag/commit a release at revision 3? When the maven-release-plugin finishes the release it usually commits the modified POMs to trunk.
I'm happy about any kind of information or advice here, so feel free to point me to books (like http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912), blog posts, Jenkins documentation... Maybe I'm completely on the wrong track.
By default, the release plugin creates the release based on the contents of your working copy, it just ensures that you don't have any uncommitted content before doing so. AFAIK it doesn't force an update of the sources, as that's usually the job of the Continuous Integration system (Jenkins in your case). So whatever is checked out by Jenkins will be released.
What you're trying to do sounds more like a configuration change on the Jenkins side, pointing it to the right revision.
On the other hand, if the POM files are modified as part of the release, but have been changed in SVN in the meantime, you will run into a conflict when Maven wants to check in the modified POM files. That's a situation that might happen, depending on how for back you want to go with the release.
Based on this, it might make more sense to always create a branch before doing a release. So you would create a branch based on revision 3 and then create your release in that branch. This way, you wouldn't run into issues with committing resources that have changed in more recent revisions.
Creating the branch and checking it out could probably be automated through Jenkins and Maven as well.
As far as I tested it, it is not possible.
More explicitely, as nwinler said, when you release, maven try to commit the modified pom. But, if it's an older revision than the current one, SVN will complain that your sources are not up to date. So it won't work. ... as far as I know.
You may read docs about promotion build. I don't find any one clear enough to be pointed out (in th few minutes of the writing of this message).
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.