239,165
Like
Share
ReportWhat 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.
*This post is locked for comments