How difficult and/or expensive would it be to simply deploy a test Gentran environment? That's what we do - we have a replicated test environment and use appropriate controls to move stuff between test and production when the time comes to move a map/TP/whatever.
It simplifies your administration: Everyone on the prod server has read only access, period. Except maybe for a 'firecall' ID which gets used for emergenices and rigorously audited. IDK what the licensing costs are for a duplicate server setup, but this is what I would do if I were asked. Actually, you should have three: Dev, QA and Production. You develop in Dev, move to QA for acceptance testing and then into production. * Nothing gets changed in QA. * You can never move anything out of QA except into Prod. * You can move from Prod to Dev (to start your next round of development.) * And your migration procedures (again, audited rigorously) will have the procedure to delete from QA once the prod move is made and successful (but you should never be able to delete from QA manually, either.) Hope these ideas help. -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 9:14 AM To: [email protected] Subject: [EDI-L] Change Request documentation/control for Gentran NT Hello group, I am trying to get a handle on tracking production change requests. Our company has a one person EDI department, I am sure many others out there can relate. Being a one person shop, I have had the liberty of changing things any way I want and tracking (or not tracking) the changes any way I want. We were a privately held company up until February 1st and as such, no audits were required. Now that we are public, I am expecting that we will have an audit and my current way of tracking will never fly. We have Gentran on an NT server. We do not have a test system. For 10 years now, we haven't had too many problems with "production control", but, I would like to organize this a little more and document changes within some type of structure. Gentran on the NT server does not enforce any production change control or version control. You have to create your own. My goals are to create a change request system for documentation purposes and to find a way to limit the risk of production maps and other scripts from being overwritten by development efforts. I am splitting my personality and pretending that I now have a multi-person EDI support team. One person is the Manager and the other person is the developer. My other reason for doing this is in the hope that I may actually get another person to back up the EDI efforts, and need to have procedures in place for that person to follow. The first thing I want to tackle is Map control. One thing I have done over the years is to put a version number in my map name. When I do update a map, I rename it to a higher version. I have my Maps directory subdivided into four categories, Dev, Prior Versions, Production, and Test. I am thinking that I could put a "read-only" protection on the Production folder and "read-only" on the TransObj for all users other than my server main, overall user. Then, the only way you could move a map into the Production folder or register it in production would be if you have access and can sign on to the server. Would that work? Each developer will have their own TEST trading partner. Any testing is to be done only with this partner. They would change the Map Summary Description to be Test_whatever for the TEST tp to find it when it is compiled and registered, and so the real trading partner doesn't find it. Developers, when finished testing, would put their map in the Test folder and submit a request to the manager to do a quality check and place the map into production. Developers would keep their development version on the server as opposed to the client in order for the whole EDI team to be able to see which maps are being worked on. Can't see this if the maps are on the client. Ok, all that being said, any one out there already do this? Do you have some suggestions for me? Any feedback would be greatly appreciated, thanks, Cindy [Non-text portions of this message have been removed] ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix. Yahoo! Groups Links [Non-text portions of this message have been removed] ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
