Hi Dale,
I will explain how we work, that might give you some ideas.
1. Development
Every developer has their own local AX environment (one per customer they have to work on). This is because when you work on the same AOS and you debug CIL, the AOS hangs so other people cannot work while you do that.
We use TFS for version control, so we check in our code and it is stored on TFS.
2. Builds
We have setup up a daily build that get all sources from TFS (so everything that is checked in), creates a model for it (actually 2 models, one with the code and one with the label file) and deployes it on the TST environment.
Our method (currently) is: We have setup an AOS specially for building, this synchronizes with TFS and starts a full compile and full CIL overnight. When this is ok, the models are exported and imported in TST, where an other full compile and CIL is done. In the morning, all new code is available in the TST environment.
This is all don in command line scripts and using a AXClient, but we are in the process of migrating to TFS Builds using the build scripts developed by Joris: dynamicsaxbuild.codeplex.com.
3. Release to the customer
You always (always!) release using models. This is the way code get to the customer site. Models are similar to aod files (layers). Never ever import xpo to deploy code because you cannot possibly track this and it will result in errors. I am strongly against importing xpo's in production, an also against compiling and incremental (or full) CIL compiles. On my projects, no-one is allowed to import xpo's, (and really, no one wants to either :)).
If you want to deploy to an environment, you should take that environment down and import your model files. Then restart the aos and do a full compile and full cil (a compile can be on level 1 for example, no need to check all best practices). These actions will be automatically presented after you restarted the aos.
However, usually you don't want production to be unavailable for this long (all these steps will take hours). To solve this, you should set up a "build environment" that is a copy of your production. Simply restore the prod database over this environment before you start importing models. It is also an option to import the modelstore from production into this build environment. The important thing is that the modelstore of these environments is the same. Even better is when all data is the same so you can also detect data synchronization errors beforehand.
Import your models into this build environment and perform all steps you usually do like a full compile, full cil etc. Then your modelstore is compiled and you can export is from the build environment to a file. On you PROD, create a temporary schema using axutil and import the modelstore from build into that schema. Then stop the prod aos(es), apply the schema and restart the aos(es). During this step PROD will be unavailable but this usually only takes minutes which is usually acceptable.
After that, prod is available, although depending on what you changed in code, you might have to deploy some reports or enterprise portal controls/pages.
To sum up:
- Each developer should have their own local ax environment
- Use TFS
- Set up a build
- Release using models
- Release to PROD using a modelstore that is build on a copy of production
- Never ever use XPO and do not compile in PROD, you will have trouble.
Hope this helps.
