1

I've been reading quite a bit, but I can't find any articles that fit our use case (maybe I'm blind), I'm after some suggestions or articles to read.

We have a couple of outsource teams who currently use SVN and I need to get them using our source control (Mercurial -Kiln) to enable use of CI/CD -AppVeyor. So there are multiple teams, working on multiple features (and of course with changing priorities).

Overall, the trunk has to be production ready at all times and is setup for CI/CD. Currently branches aren't part of CI/CD, only trunk, but we could introduce a dev & qa branch so builds could be automatically tested and deployed and hotfixes applied more easily).

We have a Dev->QA->Prod release process, however as priorities are changing or some developments are more complex than others, we end up in a situation where feature A (complex) and feature B (simple) are developed at the same time, feature A moves to QA (and as its complex takes time to test), whilst testing A, feature B is also moved to QA, tested and ready to go into production, however, feature A is not ready yet (or has changed requirements) so we can't push feature B into the trunk as it is already merged with A (sorry, I've tried to simplify this explanation, oh look, a high priority hot fix and tiny feature is required in production immediately).

Now in the SVN world our outsource team seems to be able to cherry pick changes and merge them into the trunk, so they don't have this problem (I noticed hg graft, though I don't fully understand its tradeoffs/repercussions).

Does anyone else have a development process as "flexible" as this, and how do you overcome the bottleneck and apply CI/CD?

My current thinking is to treat branches independently (test etc) until they are ready to be integrated into production, then the CI/CD through dev/qa/prod takes over.

5
  • 1
    You need feature switching. Wanting to avoid releasing incomplete features is a poor reason to move away from continuous integration to a long branching model.
    – Mr Cochese
    May 8, 2017 at 9:05
  • Changing your source control system just to please the CI server seems a bit risky. Have you looked for CI solutions that work with SVN?
    – RubberDuck
    May 8, 2017 at 9:48
  • @MrCochese correct, I'm trying to move toward it, currently it isn't implemented
    – Mr Shoubs
    May 8, 2017 at 10:42
  • @RubberDuck we don't use SVN, only the outsource teams do...we have our own source control that manually copy into... all something that was happened (apparently not agreed) prior to me.
    – Mr Shoubs
    May 8, 2017 at 10:43
  • Ok. That's different. It's absolutely not unreasonable to ask the outsourcing company to use the same VCS.
    – RubberDuck
    May 8, 2017 at 11:46

1 Answer 1

1

Theres no real solution to this problem of 'ive got two features merged but I just want one of them'

Its sounds like your external team are manually picking out the bit they want and making a new branch. The problem with this is that the testing they did on the merged version is not good for the new picked apart version. You should test again from scratch.

Your alternative of not merging a feature untill testing is complete has its own problems. A you need a tonne of QA environments and B if branch B completes QA and is merged, then you have to retest A, C, D, E... etc with the new master merged in.

Feature toggles and the like dont really change the situation. You assume that a turned off feature wont affect the code, but that's a false assumption. Plus you end up with an extremely complicated setup/configuration with combinations of features being on and off to test.

The best advice I think, is to keep the features small and finish what you start before moving on to the next thing.

2
  • Your advice is exactly what I would like to follow, unfortunately this does not meet the requirements of the business so is not always possible to finish what we started. QA environments aren't an issue, you are correct about having to retest, but I think that is the only option we have in the current situation, plus there are some automated tests, so that minimises testing.
    – Mr Shoubs
    May 8, 2017 at 13:10
  • picking out the branch when required is prob the easiest then. At least then you can minimise the times you have to do it
    – Ewan
    May 8, 2017 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.