Query regarding docker, test environments and dev workflow

I am a QA automation engineer and I am investigating docker as a potential way to run our tests.

Traditionally we have followed the git flow method where essentially where you have a dev and a master branch. Dev are constantly merging their new changes to the dev branch. When we wish to release, we will have a code cut off, where everything currently on the dev branch is deemed to be part of the next release. Script is then run to create the release candidate and this is deployed to staging. Any fixes that need to be done are made to the release branch and once ready to go to prod, new code is merged to master and deployed. Master is back merged to all branches so that everything is up to date. (described in more detail here: http://ift.tt/mixx0f).

So my question is with docker do you need to have this workflow? Im thinking of maybe having a workflow like describe below:

• Dev start working on a new feature.
• Dev pulls master, creates feature branch - does his dev work - unit tests pass, dev is happy for work to go to QA
• Dev runs script to create release candidate (which would involve pulling master again in case new code has been merged to master by another dev),
• Docker then spins up a container with multiple containers inside that (front end app, DB instance etc)
• Tests (unit, api, selenium integration etc) are then run against this release candidate and if good deploy to production.

So do I need a staging env in the traditional sense where it is constantly available?