Eric,
I have done this implementation in a few projects. in my case we did it as:
DEV to QA
QA to Prod
when you have change recording enabled, you have contributors to changelists. Once a contributor is ready for its change to move up, they will have to approve. once all contributors approve the changelist, then it can be released by a leader. The changelist will only be visible from the upstream environment after it has been released. Since HALM uses a pull mechanism, then you will need to log in to your QA environment and request a pull from your DEV system based on your changelist ID. notice that the changelist ID will be difference once it gets to your QA environment. if the tests is accepted in your QA environment then you will need to go to your prod environment and pull from your QA system. if your change is not ready.. then your developers will make new changes to a new changelist on DEV and go thru the approval and release process again.
once your changes are again in QA and ready for prod migration, your authorized user will need to go to the prod system and perform a pull from QA.
DO NOT:
- make dev changes on your QA environment
- turn on and off change recording
these will cause changelist corruption and you will not be able to transport your changes
- mix changelists from different delivery units
DO
- keep your changelist approved and migrated.
- keep your changelist from the same package under the same Delivery Unit.
before getting deep into programming, etc,.. make sure you can transport a simple easy and minor change.
good luck and hope it works out for you.