A Remedy deployment is commonly composed of three sets of resources: development, test or pre-production and production environments. By definition, pre-production and production environments must be as similar as possible, in order to test developments with the maximum guarantees. But the development environment has another objectives and needs, so its configuration is not need to be equal as the production environment, and some special configuration parameters are recommended.

In this post I will cover those differences providing a guideline of a development environment configuration.

Non unique solution

First of all I want to state that there is no magic guideline, and every configuration aspect must be considered separately for your case. In this direction, I will focus this post in showing you the main aspects of each covered configuration parameter, allowing you to decide if this case applies to you or not.

AR System Administration: Server Information

All configuration parameters described in this post can be found on the AR System Administration: Server Information form, accessed from the AR System Administration: Console. They are under tabs Configuration and Log Files.

Allow unqualified searches

This parameter is highly recommended to be unset for production environments since a user can severely degrade server performance if makes an unqualified search over a highly populated form. But it is also an annoying setting for development, since it is very common to search for all the contents of a form. So my recommendation is to set it on development, but unset it on production.

Development Cache Mode

Normally if user are acting over an object and a change of this object is made by a developer, the system gives priority to users, delaying the object change. That is, making development having a less priority over user activity. Setting this option, changes terms, and changing actions have higher priority (resulting in a degraded experience for users).

I think that it is very clear that the recommendation is to unset it for production environments, and to set it on development environments.

Record Object Relationships

Trying to reverse engineering an app without the object relationships at the developer studio is a hard task. Questions like “Which active links can change this field?” are difficult to answer. So you must set it for your development environment to enable these options at the developer studio. On the other hand, since no development studying is recommended on production servers, there is no need of this option (which consumes database and delays any code upload to the servers).

Client-Side Logging Group

This option allows you to grant a permission group the right of seeing server activity at the client. It can be a security hole if all users would be able to see it. So you must control carefully it. By default it is set to the Administrators group. But I recommend to set a different group, so you will be able to allow non-admin user to see those logs.

My recommendation is to set a wide-spread group for your development environment. Any user at the development environment is a test-user. So it is really helpful to allow them to see those logs. But for the production environment I recommend to use a group where you can dynamically put or push users. So your support team will be able to switch it on for a certain user and execute a log when needed. But all users by default (except admins) won’t be allowed to see those logs.

Object Modification Log & Save Definition Files

This options tracks any change on ARS objects, so you can track them and restore them if needed. My recommendation is to set it at your development environment. To save resources, unset them on your production environment.

Passwords for critical accounts

There is a set of users and related passwords that are critical. Examples are: Demo, AppAdmin, Mid-tier, DSO, Database, developers accounts, etc. If an evil user would get one of those passwords, bad things can occur. So it is a good practice to set secure and different passwords for all those accounts for your production environment. But, development environment doesn’t have those security constraints, and it is a good practice to have an easy password for all those accounts.

Also to have different passwords on development and production environment prevents your development team to connect to the production server, thinking they are on development.

Buffer Logging lines

This option increases performance, delaying the appearance of log information. Think a bit about it, do you need to see the log immediately after it is produced? For a development environment it is a rotundnous yes. But it is not true for a production environment. At production you normally see logs of something that has happened several hours ago. So, the recommendation is clear, set it on production, and unset it on development.

RRR|ConfDif

All those parameters are stored at the ar.cfg files. It is a good practice to compare the files on all environments (development, test and production) to control the differences. But comparing ar.cfg files is not as easy as it can seem since you can find commented lines, configuration placed in different order and other stuff that makes this operation slow. RRR|ConfDif is a free tool for personal use.

Download RRR|ConfDif

Special Thanks

I want to thank arslist’s people that helped me on designing this list. Also, if you think that you can contribute to this list of configuration parameters, feel free to comment!