What is isolated environment?
The isolated development environment means that every developer has his own, isolated code to work on. It also requires a separate database (different applications may have different database schema) and preferably an isolated operation system and all other needed components. Details depend on exact needs and available facilities.
Axapta, now Dynamics AX, has significantly evolved in time – it began as two-tier application, then added the application server, web portal, .NET Interop, SSRS and many other things. It now offers much more features, it scales better, it can easily collaborate with external systems etc.
For implementers and ISVs, the complexity and size of projects requires (among many other things) appropriate development procedures. Using isolated development environments is one of such things – if multiple developers work in the same environment, they may block each other, they can’t trust any tests because code and data may change at any time, and so on.
Unfortunately, most AX teams are used to the model of shared environments and don’t want to change it, despite all obvious and frequently occurring problems. They lack an effort to avoid problems and knowledge of how version control and related processes work.
Is also true that Microsoft hasn’t make much effort to help partners to adopt the change.
Now we have AX2012 and although it made shared environments even more difficult to work with, many AX teams waste their energy to adjust AX to support shared environments rather than to change their own approach.
Some companies also try to use shared environments with Team Foundation Server as version control system. This scenario is not supported – you can use it, if you really want, but you have to be prepared to solve some issues. Unfortunately, companies typically ignores them unless they get first-hand experience.
To build the process and get used to isolated environments costs time and energy as well – but it solves many problems and brings new opportunities.
I wrote down a brief summary of differences between shared and isolated environments for a client with AX2012 RTM and Team Foundation Server 2010 – sees table below. Although it is focused on this specific configuration, many points are valid universally.
The summary takes some information from Microsoft’s White Paper Developing Solutions in a Shared AOS Development Environment – don’t miss it, it provides additional details and guidelines.
Isolation and parallelism
| Shared environment | Isolated environment | |
|---|---|---|
| Parallel development | Not possible – there is just one code base | Developers can work on same objects in parallel |
| Isolated development | No isolation – one developer can block all others | Complete isolation – no changes in code affects other developers |
| System isolation | No isolation – there can be just one setup of AOS, OS, IIS… | Different configuration can be used by each developer |
| Data isolation | No isolation – the database is shared | Data are isolated – no unexpected changes in data. Data sharing is complicated |
| Changeset isolation | Changesets are not isolated. This leads to interconnected modifications that can’t be easily used independently. | Changesets are isolated and their sequence is always clear |
| Latest version | Always contains the latest version | Developers must obtain latest version from server |
| Operation | Concurrent operations such as compilation or CIL generation are not supported. | No conflicts |
| IL debugging | Breakpoint in CIL running on AOS blocks the AOS – a separate AOS(‘s) is needed. | AOS is not used by others = no issue |
Branching and merging
| Shared environment | Isolated environment | |
|---|---|---|
| Branching | Not possible. Workaround: Separate shared environment for each branch |
Different developers may work on different branches. Switching between branches (and synchronizing database) may lead to data losses. If this is a problem, one database per branch may be a solution. |
| Handling conflicts | No concurrent development = no conflicts | Merge is needed in case of parallel development |
TFS Workspaces
| Shared environment | Isolated environment | |
|---|---|---|
| Type of workspace | Shared workspace (several limitations, e.g. it’s possible to modify an object checked out by somebody else) Private workspaces – requires modification |
Private workspaces |
Maintenance
| Shared environment | Isolated environment | |
|---|---|---|
| OS maintenance | Single machine | Multiple machines – more resources needed; more complex architecture |
| Database maintenance | Single machine | Multiple databases – greater space consumption |
| AOS restart impact | All developers are affected | Just a single developer is affected |
| Network failure impact | Typically blocks all development | If local environments are used, development can continue. |
| Licensing | Terminal Server licenses needed | More licenses needed, e.g. for OS |
Performance
| Shared environment | Isolated environment | |
|---|---|---|
| Isolation | No isolation – heavy load caused by one developer affects others | Logical isolation, in fact it depends on configuration (multiple developers on a single HW machine may experience similar problems as with the shared environment) |
In general, isolated environments are invaluable if several developers work on the same codebase, which is the rule rather then the exception, especially on ISV projects and bigger implementations. They may not be worth on really small implementation or when providing support fixes rather than proper software development.
Great article Martin, as always. I do have a few comments on this though.
1. I agree isolated environments have significant benefits, and the shared environment is an artifact of AX history for the most part. However, a key issue that makes most VARs stay with shared environments is that VARs need to support multiple clients on multiple versions of AX. If you have 20 clients and 10 developers as a VAR, you’d need 200 AOS instances if you want to do isolated environments.
2. You list changesets not being isolated in a shared environment. Isolating changesets is key to branching and merging. I’m not sure what you mean by that. We use shared environments and changesets are clearly isolated. Could you elaborate on the issue there? Perhaps you are talking about a shared workspace scenario?
3. You say branching is not possible in a shared environment and you need a separate shared environment for each branch. Branching in itself is perfectly possible, of course, because it is a concept that exists outside of AX. In an isolated environment scenario you’d also need to hook into the specific branch, if you want to make changes on that branch. I guess I’m not entirely understanding the issue you are bringing up?
All in all the shared environment scenario has worked really for us, granted with several customizations to the AX – TFS integration. AX 2012 has brought challenges – mainly around CIL. Other than that it works well. We are exploring ideas around using isolated environments – but so far we have not found any practical means of accomplishing that, due to the amount of (virtual) servers and resources we would need to support that.
Hi Joris, thank you for your feedback. I admit that the tables are very brief, so it may not be clear what they exactly mean. I may discuss some of them in later posts, but it was out of scope for the moment.
About you items:
1. I understand your point, but I don’t completely agree. What you really need is to have one environment per developer and AX version (that includes minor versions too). So if you have 20 clients using 5 distinct AX versions, each developer will have one running and 4 stopped AX. If you need full-OS level isolation for some environment, you can build it as a virtual machine (again – stopped until needed).
I agree that you don’t want it if you need to switch environments rapidly or you don’t expect any concurrent development. That’s what I mentioned at very end of the post.
2. I considered discussing this point in better details but I decided not to bloat the row. Well, I’ll address it here.
To have all branching, migrating etc. easy, I need to have clear sequence of modifications. Feature A with all its objects is older, feature B comes later etc. Simple. And I can achieve in shared environment when I lock all objects needed for the modification and check them in at once. It means that I block (potentially) lots of objects, which is a big problem, but it would work. Unfortunately, we often don’t know what object will be needed. Therefore a developer works and finds that he needs an object checked out by somebody else. He can stop and wait, possibly blocking other with the same problem. But we can (and we do) get into deadlock – then either one change needs to be completely removed or people check in (“free”, how they say) the conflicting object, allowing others to work. The first approach means unnecessary manual work, the latter breaks changeset sequence in version control (an object for F1 is added, then something for F2, another object for F1…).
These situations can be largely avoided by good planning (we’re usually able to say where conflicts are likely) and breaking-up changes to small pieces, but most partners have serious problems to do it.
Do you think I missed something important in this process?
3. Of course I don’t mean that using a shared AX environment will block the branching functionality of your source control. I used this point to explain the client that isolated environments are prepared for branches – I can, for example, simply branch from an older version and synchronize to make a bugfix. With a shared environment, I have to either stop all work on current branch or build a new environment. (This AX-per-branch model works very well, I just wanted to show that they will need more than one AOS anyway.)
What I usually see are teams trying to develop in parallel in a shared environment and it simply doesn’t work. Or they want to be able to remove or migrate individual features but they don’t keep them in changesets – and have a lot of troubles about it later.
My point is: think carefully what you need and choose the most suitable. If shared environment works well, so be it. If not, look for something else.
Sure, this post is mostly propagating isolated environments – it’s because this model is still too overlooked and because the original presentation was prepared for an ISV project with several geographically distributed developers.
Hi Martin,
1. You still have an issue with the AX client not supporting multiple versions installed at the same time. As for the AOS, your approach would work. However, with 2012 you need reporting services, so you’ll need several reporting server instances (which is now supported officially and explained in a whitepaper), and any EP development would have the same. Running this all locally will become difficult if not virtually impossible. With Windows 8 we’ll at least be able to run Hyper-V images locally, but still, as I said, the whole thing is extremely impractical for now.
2. The only thing you may be missing is that “breaking the changeset sequence” is a non-issue. TFS takes care of these conflicts mostly automatically, the new version of TFS should be able to handle 99.9% of cases. So far this changeset-sequence has not proven to be an issue at all for us. And in either case, I don’t see how an isolated development environment fixes that, unless you actually have each developer working in his own branch and merging into a shared main branch (which is the recommended .NET dev approach). But if you do that, you’re just exchanging one potential issue for another (actually, I see less issues with the development on the same branch with broken changeset sequence).
3. I see your point here, in that you would stop everyone else from making changes by switching branches. You’d have to setup another AOS where technically if you have your own AOS you could just synch back-and-forth.
I agree that developing in parallel requires knowing very well what you’re doing. However, we’ve done it for years now and it worked extremely well (granted we have several customizations to the AX integration with TFS). For 2012, the main issues are around CIL, which is not a version control issue but a development issue in general. The other 2012 issue has to do with multiple models, which is not exactly solved by isolated environments but more circumvented.
Like I said, I’m all for the isolated environment approach – if and when I can figure out how to overcome the limitations. And for now, I have limitations to overcome on the shared environment (since we’ve solved most if not all by now).
1. Multiple clients are not supported by the installer, but it’s not a problem to use them. I and many partners use them every day. Reporting services – similar story. But again, it all depends on your exact needs.
2. I think you misunderstood what I’m talking about. I don’t mean “TFS changesets”, I mean “logical changesets” or “single modification”. What people do what they meet problems described above is to check a part of work prematurely, so one “logical changeset” is in multiple “TFS changesets”. The other thing that people do is to include code for more modifications in a single TFS changeset (this is bug in their process anyway). There in not much what TFS can do about it.
Your experience is that shared environments work well, so use them, no problem. My experience is that companies ask me how to allow seven developers working on the same module without blocking.
By the way, we do use isolated environments on my current project.
One additional thing. In complex scenarios (that are the ones we have to deal with most of the day) we might need the original database or at least a blackend copy of the huge database to test the code. Let’s say we have BOM’s with 20.000 of items. So the database would have somthing like e.g. 50 GB. If you would support 20 customers you would need 20 Customers * 50 GB = 1000 GB of disk space only for one developer only for database space 🙂
It’s generally bad idea to use such databases for development, it has also other consequences as poor performance etc.
Use light databases for development and keep the full-blown database in your Test environment instead.
Hi Martin,
Thank you for taking the time to draw up these differences.
I am currently an IT intern trying to “test drive” isolated development for my company. I have already setup TFS version control with branching for AX2012. My next step is to create a light development database like the one you mentioned in your reply above, but I have been having some troubling finding out how to do this. Do you have any recommendations or resources I could look into for help with this?
Thanks for your help!
You have basically three options:
a) Build the dataset from beginning.
b) Use demo data as the base.
c) Use customer data.
I’m strongly against the last option. It has many problems, including legal.
Although I use the a) in some environments, it’s usually more efficient to get some base data for free, i.e. to use demo data. Some partners also build demo data for their solutions on top of standard demo data, so you can use them too. You still have to add data for your own features, if needed.
Interesting article and nice discussion 🙂
Although from a developer’s point of view I’m all for isolated environments, I agree with Joris that the practical implications make it difficult for companies with several customers. For example, most of our development is not done on environments at our company, but rather on environments at our customers. For isolated environments that would mean each customer would have to provide the necessary ressources that we would have to administer for each customer.
The question is if the gain from isolated environments is so great that it outweighs the greater complexity and additional ressources it brings with it. My guess and experience is no, even more so if you have experienced developers that know what to look out for in a shared environment to prevent conflicts and other headaches.
Although this sounds rather critical towards isolated environments, I would love to see Microsoft reduce the complexity and resource demand for this so it becomes practical to use.
Again, if you don’t need to solve the problems addressed by isolated environments (concurrent development, isolation, local development…) you really have no reason to complicate things. But some other teams are in a different situation than you.
Hi Martin,
Hope you’re doing well. I was hoping you could help me out.
I’m currently setting up a customer with multiple isolated development environments which use TFS for source control. I have a separate machine that is used to check out the code and run a full build nightly. I then have another AOS which I am using for system testing and then a pre-production AOS.
I plan to use model stores between pre-production and production, but I’m struggling to work out the best way of moving code between the dev build machine, test and pre-prod. Have you got any ideas?
For example if something fails in TEST then I won’t want it moved to pre-prod. Am I best off having a branch for each stage in the process?
Hi Nick, it’s not easy to say what’s the best for you, every project is different.
About the first part, you have to – at some moment – fixate IDs for the required model store and then move only the model store. I would do it before moving to test (i.e. everything would go by model store from there), but it depends.
About the latter point, you mean you would remove the failing thing and deliver the rest? The solution depends on your branching strategy – e.g. you may just rollback it in Main and leave in Dev (if you have them). With a single (main) branch, I would probably either wait for a correct build or really make a new branch. But it’s not clear to me what you mean by “each stage”. I would rather fix the release than making even more branches.
Hi Martin, great article.
AX is built for share development. I see the discussing as blocking problems in a AX shared development environment as nearly non-existing contra the overhead of using TFS for a isolated development environment. In fact I agree on that a isolated development environment will destroy your development capacity (http://www.derekhammer.com/2011/09/11/tfs-is-destroying-your-development-capacity.html).
In my opinion the gain from a isolated development environment overshadow the complexity of the setup you will have to deal with. Also I see the TFS integration being too immature to replace shared development. Besides by using TFS you will introduce another crtitical system to your AX installation.
As Florian mentions for experience AX developers shared environments is not a problem. You just have to plan your build releases with that in mind.
You will be much better of using shared AX development and organize your build releases in Jira or a SharePoint site and do layer or model deployments. I practice myself, that any mod made to system should be traceable for any developer on the team at anytime. You should easily be able to lookup all changes done for a mod and the history of a mod even if the mod is 3 years old. I would expect TFS to provided me with such information in a easily and quick way, and I cannot see the value of isolated environment/TFS before this is a reality.
Hi Steen, I fully accept that you don’t need isolated environments, but to say that requirements for concurrent development or isolation don’t exist is really daring statement. All the companies around the world who adopted/try to adopt this approach don’t do it because they’re bored, but because shared environments don’t suit them well. For example, having 10 full-time developers in the same environment is simply a problem.
I must also say that I don’t feel our development capacity is destroyed. Why do you think it would happen?
Your link basically says: “I don’t like TFS”. But that’s not really related to discussion about shared vs isolated environments. You can use isolated environmentd without TFS (I now work on isolated AX2009 with SourceSafe) or use TFS in a shared environments. But even if you don’t like TFS – what better supported by AX out of the box?
Hi Martin,
My point was that using TFS to prevent blocking problems is way overhead. In fact my experience is that TFS can easily cause blocking problems. The more developers using isolated TFS, the higher risk for blocking problems. Say, if a developer forget to check in an extended data type or rename an element. Then all other developers will get best practice errors if trying to check in changes to the same table. This is just some of many overheads using TFS, besides you spend a lot of time to sync with TFS, merge code on check in and copy test data. You could argue just to disable best practice validation on check in and not to rename elements, and that is in my opinion one of the main problems, people will bypass such checks, and thereby lower the quality of the code to have the TFS sync/check in working more smooth.
What is your problem having 10 concurrent developers working in a share environment?
I think using TFS in a shared environment is a better alternative, but as you mention this is not supported. Besides I see the TFS integration as primitive. To have it works better, the check in should be more granular, it ought to be possible just to check in changes to a single class method.
Unfortunately Microsoft does not provide any other alternatives. I always suggest my customers to use an AX development tool combined with a project site to manage the mods. I can recommend an AX tool called Source Code Manager from addonax.com. Using SCM in a shared development environment with a SharePoint site to keep track of your mods/builds is in my opinion a much better and more simple alternative to TFS and you will not have to add another critial system as TFS to your environment.