Total Cost of Ownership of BPPM - Part 9: Best practice - Store only one copy of the same file

In the previous post, we discussed file repository where you store all your customization files. It simplifies deployment because you always know where the most up-to-date copy of each file is located.  However if you keep more than one copy of the same file in your file repository, these multiple copies can become out of sync and then you have to figure out which one is the most up-to-date copy when you deploy.

How can you end up having multiple copies of the same file in your file repository? Different server roles and different environments can require different file content with the same file name.  For example, .load file would be different for your PATROL cell and for your correlation cell.  IBRSD.conf file would be different for your development environment and for your production environment. 

Does this mean that you have to have separate file repositories for different cells and different environments?  No.  Since most of the files are still the same in both your development environment and your production environment, having separate file repositories can make them out of sync quickly.

Because only small percentage of customization files are different in different environments, I simply use a renaming method to store and deploy them.  For example, since IBRSD.conf is different in development environment and in production environment while most of other IBRSD files are the same for both environments, I store both copies of IBRSD.conf in my file repository as IBRSD.conf.dev and IBRSD.conf.prd in the same directory.  When I deploy IBRSD to a production server, both IBRSD.conf.dev and IBRSD.conf.prd will be copied to the destination server.  Then I will run a post deployment script to rename any file with a .prd extension to its original file name without .prd extension.

By using this renaming method, I can handle a small number of file variations while avoiding to store multiple copies of the same file in my file repository.  This method also keeps the size of file repository small.

Having a small file repository means that you can back it up on a thumb drive as the files are mostly ASCII.  In a catastrophic situation, you can rebuild your entire system quickly at another location with exactly the same customization you had at your original location.