Testing environments

Hi George,

If you are no already doing so, you may want to look into using Roundtable together with your Dynamics setup. You could use RTB to manage one or more test environments. Importing changes from your development into these workspaces (with their own icfdb databases) can be done by RTB - including loading changes .ado files. This can take out a lot of the manual work in keeping track of which ados to load and manually getting them loaded. Loading .ados on import into a workspace is part of the integration between RTB and Dynamics.

You could also use this setup with just one central test environment, which has an ICFDB database. When this has been updated, you can replicate the environment (database, source, r-code etc.) to other test environments if needed. Otherwise you could have shortcuts and configuration files setup up so that you use the same codebase but different databases etc.

We have developed a toolset for automating parts deployment processing from Roundtable. This can also be set up and configured to automate the creation of test environments, either within a workspace or with the use of Ant scripting to automate the replication of environments to other directories, machines etc. Contact me offline if you need more info on this.

Regards

Thomas Hansen

Hi Thomas,

thanks for the quick response!

Unfortunately a Roundtable license does not make financial sense for us (we got a ludicrous high quote for a roundtable license).

We had to develop a custom source manager that moves our changes from our DEV environment to our master QA environment. This tool also manages rejecting and accepting changes made by our programmers and storing approved code (ados etc) in a CVS repository.

The one option would be to expand our custom solution to update multiple QA environments (possible time issues). Or alternatively just 'hitching' customer DBs onto our master QA ICF db. Hence my question on the implications of useing one ICF db with multiple custome dbs. It sounds like Roundtable does something similar for you.

Regards,

Georg.

Hi again Georg,

I cannot comment on the quote you got for a RTB license. But proper SCM does come at a cost. But I am sure many of the existing RTB customers will agree that it is worth the cost. Contact me offline if you are interested in exploring this further to compare with what you have received already.

Back to your questions. The impact on using a central ICFDB will very much depend on what kind of information in the ICFDB repository that your application is using. The main impact of multiple envrionments using the same database would be things like :

- the sequence values that are used to create _obj field values (if you are using this in your database design)

- if you are using Dynamics sequences for record references, you may have problems with gaps in your numbers. This could be avoided by settingup login companies for each clienht setup and then set up sequences that are login company specific.

I cannot think of any other areas where this would pose a problem.

I expect that main problem you would have would be more basic things like ensuring that your customers databases and the r-code for your setup are in synch so that you do not get CRC errors.

Regards

Thomas

I really don't see an issue why this should not work. I used it in similar situations when switching the testing environment from a handy database stored on a notebook to a big test db on a server.

The session configuration makes it easy to set up database connections. You could also introduce a new session parameter that lists the available login_companies for a session, so that you may limit the login_companies available for a test database. You'd need to write a custom login screen (if you haven't already) to filter the login_company combo box.

I think the most difficulty will be to ensure that the schema of the customer test dbs do match the datafield and entity information in the icfdb. If they do not match 100% this will raise runtime errors (at the client or in the appserver logfile) that sometimes are hard to capture without swome experience.

Next thing would be that the CRC values of all your customer test databases should be identical. Otherwise you'll have to compile your business logic code over and over again.

_obj values should not become an issue - they are completely managed inside the icfdb and can grow very, very large.

I know RTB is not 100% for free - but I guess you need to invest at a point (either in money or in time). I've built a deployment scenario for Dynamics applications that works well without roundtable and can be adopted to any SCM tool (I use Perforce). In the dev environment I do dump the ado files frequently (manually or automated using session triggers) and mark them for add or edit in the SCM tool - similar to RTBs approach. When integrating these changes into another environment (one of the testing environments), I have also automated the process of loading these ado files based on this routine : http://www.extreme-dynamics.org/ManualADOLoad . Together with this I've also automated the load of delta df files accross different test/prod enviroments.

No matter if you do this with RTB or your own scripts/routines, you need to consider that loading a lot of ado files takes it's time. If you constantly change your dev environment and you'd need to populate these changes to a bunch of test environments, that's gonna multiply this time. You'd better have this scripted in a way that can be run unattended.

Mike

Hi!

Thanks for all the feedback! I should have replied a lot earlier...

Our QA environments are now 'hitched' and I found that I needed to deploy the follwing information:

gsm_currency.

gsm_group_allocation

gsm_login_company

gsm_user_allocation

gsm_user.

I modified our ADO deployments to only load changed ADOs. I compare the ver_number_seq of the ADO with current version in the target ICF db - using the gst_record_version.

Obviously there is still a lot of work for our testing environments, but atleast we now have mulitple customer testing environments available without too much trouble.

Thanks again for the feedback.