| Code Portability across Environments | KEVIN RESCHENBERG
08-22-2005 |
During last week's
mention of database/environment refreshes, I
suggested restoring any associated file folders (SQR, Crystal Reports,
scripts and so on) at the same time. Now, you may think that's
too much trouble, especially if some of your custom code depends
on the specific environment. For example, you might have code
that creates a file in a particular folder or Unix directory—code
which must be changed for each environment. This issue usually
affects custom SQRs, but it can appear in PeopleCode as well.
In fact, you could have pages or other objects that are
tailored for each environment.
This is dangerous and is usually an unnecessary complication. Our objective
should always be to create every custom object in such a way that
it can be migrated to another environment without any changes.
Hopefully you have been able to avoid this issue from the start. But I've seen many
cases of this at various installations. For example, you might have
separate versions of the FILEPREFIX substitution variable in SETENV.SQC
for each environment. This means that the code must be changed manually
during every migration or refresh. What are the chances that this will
always be done accurately?
How can we avoid this issue—or at least work around it? Here are a few
suggestions.
Set up all environments' file folders consistently. If the output
folder for payroll interface files in production is called OUTPUT\PAYROLL
then don't call it PR\INTERFACES on your test servers.
Use drive letter mappings. If you have been
using UNC (\\server\folder) paths, consider switching to a drive
letter scheme using the same drive letters on each server. This allows
you to use something like D:\OUTPUT\PAYROLL instead of \\PRODSERVER\OUTPUT\PAYROLL.
Use relative paths. Instead of embedding the environment name
in the path (\HRPRD\OUTPUT\PAYROLL), consider placing these folders
within the file structure for the entire environment and using
relative addressing (OUTPUT\PAYROLL or even ..\..\OUTPUT\PAYROLL) instead. The disadvantage of this
method is that you can't centralize these folders on one shared drive.
However, your users should not be confused, since the environment name
(HRPRD) is probably part of the overall file structure for the
environment anyway. But using relative paths means you won't need
to code it.
If necessary, query the database name. If you can't avoid using
the environment name as part of a file path, don't hard-code it.
Read the database name from the database instead. For Oracle, there
are a variety of ways to get this but most people probably use SELECT DBNAME
FROM PSDBOWNER. For MS SQL Server, use SELECT db_name(). Once you have
the database name, you can construct the actual file path.
Don't create environment-specific pages or other objects. If your
users have specified that the production page should differ from
the corresponding page in the development and testing environments,
question the need for this. Explain how this makes migrations and
refreshes risky, and makes reliable testing impossible.
|
