Mostly, we're happy with doing maintenance. And our number of outstanding defects is way down. But the code we have, presents another set of risks (mostly long term) we'd like to mitigate.

We have a big commitment to release management here. We develop on one box, use another box to create and test release builds and do integration tests. After that, code migration and the DBAs run the release builds out to yet another platform for another group to do user acceptance testing, before anything goes to production. And, we try to keep a consistent environment all the way from development to production.

I couldn't be irresponsible and keep my job, even if I wanted to ...

And yeah, we have *everything* in a version control system. Actually we have 2: svn for day to day development and creating release builds, and a corporate repository run on another version control system that we commit releases to.

Regression testing is dependent on test data. We have a test data library with 30 days of anonymized production data. I'm working on a tool to use files from that library as templates for generating a stream of test files for out daily batch processes, by changing some dates and numbers in them.

The same tool should be usable for modifying another set of templates to create expected outputs. Regression testing should be straightforward from there.


In reply to Re^2: Best practices and financial applications by cleverett
in thread Best practices and financial applications by cleverett

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":