CODEWITHSUNDEEP
javagitmavenjenkinsproduction
Yoni Moses
Yoni Moses

Reputation: 173

git jenkins and production builds methodology

I'm currently using git and jenkins with maven to perform builds. I was wondering what's your best practices in terms of "building for production".

One idea I had is to create a new branch (let's call it production) and build that whenever we finished the features on the master.

Another idea is that after releasing a version (using maven:release) and build that tag.

I'd love to hear some real-world experience in that field

Any other ideas?

Upvotes: 2

Views: 1699

Answers (2)

Michael Dillon
Michael Dillon

Reputation: 32392

We are using the branching model described here http://nvie.com/posts/a-successful-git-branching-model/

All development work including hotfixes, is done in branches. Then when one or more branches are merged into master, we push to a production build and deployment. Most development is done in feature branches off the development branch. When work is merged to development it is built and deployed to a dev environment where it is used by other projects, i.e. dev is a development mirror of our entire production environment. Then when work merges into a release branch that is deployed to our QA environment. There it is subject to further testing by our QA team and when they sign off we merge to master.

I was thinking of making one change to this which is to have a nightly automerge of all features and development into a separate nightly branch which is only used one to build it and verify that we have not introduced merge problems or new integration bugs. A new nightly branch would be created each day.

Upvotes: 1

malenkiy_scot
malenkiy_scot

Reputation: 16605

You may find this article by Martin Fowler helpful.

One of the main ideas of CI is that you release code into production off your main development trunk. Now, in practice there can be some wrinkles with that approach, but at least that's what one should strive for.

We have separate branches for different customers, but not for development vs. production. When we think that a particular revision is ready for production (i.e. passes all the automated tests and subjectively has a rounded set of features) it goes to QC which then 'bless' or 'curse' it. When it passes QC the version is then tagged semi-manually. Theoretically it then can be rebuilt on-demand, but we usually do not have to build it again, as the main artifacts of the build are Release and Debug installers.

Upvotes: 0

Related Questions