0

My company is using Jenkins for continuous integration and I'm trying to move towards CD. I'm using git hub as a code repository. Right now we are merging feature branches into a uat environment and when a particular feature has been accepted the feature branch will be merged to our production branch. This is obviously dangerous because two changes could be tested together and deployed separately. Ideally we would have a package tested and deployed without rebuilding but I'm having trouble seeing how this is possible. If two people work on two different features, the first is finished, packaged and goes into testing, the second is then finished and packaged without the first? But then how can I deploy the package without invalidating the testing of the other feature? I'm not sure on the correct way to integrate features with a single deployable package.

Any help would be greatly appreciated.

Further, If you look at http://ptgmedia.pearsoncmg.com/images/chap5_9780321601919/elementLinks/fig5_6.jpg my concern is that check-in 1 can be deployed when it passes acceptance testing and that package will be deployed, but what if acceptance testing failed? Check-in 5 contains the same problem as check-in 1 so no deployment to production can be done until check-in 1 is fixed or removed. Removing the change would be annoying as there could be multiple commits to be removed, and a fix + testing could take a long time.

user663470
  • 149
  • 7

3 Answers3

2

Continuous Delivery is an extension of Continuous Integration. CI is all about evaluating your changes in the context of everyone else's on a frequent basis (if you commit less than once per day it can't count as CI)

Branching, of any kind, is all about isolating change and so is fundamentally at odds with CI. Feature branching and CI are opposed.

What most organisations do is merge branches before testing. This compromises the value of the feature branch, but retains the value of CI. If you don't do this then the CI has little real value for the reasons that you describe - you are not evaluating changes in a realistic context.

Sorry but you can't have both, they are opposites!

Dave Farley
  • 36
  • 1
  • I was starting to think I was coming at it from the wrong perspective. What we are finding right now is that the business wants some things done as soon as possible, like hotfixes, then they have other defects that they are happy to wait a week on, but sometimes those changes get escalated and need to go through quickly. The major pain point I have found is that if I try and plan a release, there might be one change that hasn't gone through testing so I can't put all of our UAT into the release and it turns into cherry-picking nightmare. I also want our release process to be really simple. – user663470 Jun 16 '13 at 09:17
0

Regarding the difference in cycle time of hotfixes vs less critical things have you looked into feature toggles? http://martinfowler.com/bliki/FeatureToggle.html

Marco
  • 1
  • Thanks for the link. Yeah I am aware of feature toggles and branch by abstraction. If I was introducing new features then I would use the toggles but we are doing mostly defect fixing at the moment and most of the team would struggle to refactor the code their changing in such a way that it could be configured for switch-over. Also the feeling of some of the team member is that the feature toggle is another thing that has to be verified and it's not worth the overhead. Some of the changes we make might take a few days to test which means our release pipeline would be blocked. – user663470 Jun 19 '13 at 10:53
0

If you want to do Continuous Delivery then branching is a no-no. Well, mostly. Releases should be tagged in SCM, the fix applied to release and merged back into HEAD.

You should also have automated tests to prove the fix actually fixes the problem. This might be hard in some circumstances. In that case the minimum you should do is verify the fix doesn't break existing behaviour (if that's the intention of the fix).

Feature toggles are good, so is branching by abstraction, however in practice this is adopted only by the most mature and experienced teams who have adopted CD. I suspect you're not at that point yet, so this will help you overcome your bump until you're more comfortable with CD.

If two features are supposed to be deployed at the same time, then I guess you should use the TDD principle of creating a FAILING test first, then implementing code to make it go green. Check that test in, so no build can move forward until you've got it implemented. This will make it absolutely clear this build isn't destined for production, as the feature isn't complete. Not a good idea for this test to be a CI, but at a latest phase of testing... providing you have multiple test phases that is!

KRK Owner
  • 762
  • 7
  • 16