I have the following scenario:

  • Joe is working on the feature-xx branch.
  • Richard is working in another feature-yy branch.
  • Their company has a qa.myapp.com environment where testers work.
  • Joe pushes code to Github repo. Build passes. qa.myapp.com is updated with the new Joe's branch, so testers can test his work.
  • Richard also pushed his branch. Build passes and qa.myapp.com is now updated with Richard's feature branch. Testers can now work, but they can't test the Joe's work.

Is there a way to create a "test-url" for each one of the feature branches above for QA team using "Continuous whatever" tools out there? If so, what is the term I should search for?

Basically what I want is to have several active Q.A. urls.

Something like:

  • feature-xx.qa.myapp.com < containing only code for feature xx
  • feature-yy.qa.myapp.com < containing only code for feature xx
  • qa.myapp.com < containing bugfixes.

Both testing url/environments should be generated after the build passes. So once QA approves the features those URLs should be gone.

Sometimes one developer is working on a bug fix and needs the it to be tested. But sometimes another developer is working in a feature and also wants it to be tested at the same time and they don't want to wait for the QA machine to be free to test his feature.

I think using Docker + Containers is the way to go.

  • Sounds like "feature flag" or "feature toggle". See this SO post. – Eric King Feb 7 '17 at 16:47
  • @EricKing thanks but I think it's not the case itself. In my case I don't want to deploy the feature. I want to test the features. – Daniel Lima Feb 7 '17 at 17:03
  • Btw... I've update the description =) – Daniel Lima Feb 7 '17 at 17:04
  • Yes, having multiple URLs configured (plus whatever backend systems like DBs) is the correct approach. Are you asking how to implement this? That is off-topic here. – user22815 Feb 7 '17 at 17:48
  • 2
    I'm voting to close this question as off-topic because it is about implementation, but would be closed as "unclear" if migrated. – user22815 Feb 7 '17 at 19:17

The way I'd solve your problems is by building from each branch instead of from master. However this would require that master is merged into each branch before if they have diverged. Then you could easily have jenkins build a docker image of each branch and have the images deployed in a manner that fits your QA team.

However, and this is a comment on the process, so feel free to ignore this:

To me it seems very contra productive for your QA team to test the code from Joe and Richard separately. If Joes work has any impact on Richards work or vice versa, when will you know that? In production? Or do you have a third QA iteration where they test that both features work in unison? It just seems lika a lot of extra work not having QA test the actual deliverable.

  • 1
    I feel like the "feel free to ignore" part of your answer is the part that shouldn't be ignored. OP has an XY problem. QA should be testing an integrated "dev" or QA branch, not separate feature branches. – RubberDuck Apr 10 '17 at 15:39

I won't change the hostname, but the context path, e.g. qa.myapp.com/feature1 instead of feature1.qa.myapp.com.

If this is a Java webappp, you could easily achieve that by changing the name of the .war and deploying it to the same container.

But then you will face the next question: you have incompatible DB changes. Or other resources like message queues. You can solve that, too, but usually this is more complicated, complex and error prone.

Bottom line: if you have the freedom to do it, go with docker.

  • Yes... I know I will face DB changes, etc. But I want to create an new entire machine for each branch. Got it? Each branch has its own fixtures, db-migrations, etc... then this will be easy to manage. – Daniel Lima Feb 7 '17 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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