You are doing this incorrectly, forget layers.
An AX model does not contain OriginId/Element Id. You want to make sure that the OriginId and Model ElementIds are the same between the Build and Production environment.
I typically go with this layout:
Dev (1 for each developer, no data, Dev TFS branch /branched off from the main Prod branch/), Build4Test (no data, Dev TFS branch/), Test, Build4Prod (no data, Prod TFS branch), Quality Assurance, Production
QA and Test is initially a full backup/restore of Production DBs, while build and dev only needs to have the modelstore imported, and must have the same License information / Configuration.
Developers would manually merge their code which are (fully or partially) ready with XPOs into Build4Test. The code is compiled, synched on Build4Test, modelstore is taken into Test based on your schedule, where in progress developments could be verified with data.
Once a code is matured enough, you would merge the TFS Dev branch to TFS Production in Visual Studio. On Build4Prod, you have to do a Version control Synchronize in AX to import the changes from the TFS repository.
The automated/manual TFS build process on Build4Prod would result in a modelstore. You could release that into QA and verify if everything works OK and do all final testing there for to-be-released code. Once that has passed, you could release the same modelstore into Production.
You could come up with your own schedule like when to refresh the full database from Production back to QA (typically daily or weekly) and Test (every couple of months). QA is a good candidate for debugging and reproducing issues that you normally should not do in Production, so keeping a fresh copy is always useful. Test could be older and have it's own ElementIds, it does not matter. Only the checked in/merged code is important which you synch in Build4Prod.
With this setup your code would always be up-to-date in Build4Prod, QA and Production, and is version controlled so if something went wrong with a release, you could roll back to a previous stable stage. Also you have an additional verification layer / safety net, before releasing something incorrect into Production. Developers would not be checking in anything that is half-baked, and XPO merge would not make Test system unavailable half the day due to waiting for developers. Using modelstores is much faster, a typical automated build is 2 hours tops, and a release is around 1 hour maximum.
This is one of the many designs you could do, and I can assure this already works like clockwork for medium to large enterprises already.
