I'm not sure what topic to post this under, so I'll try here.

Our Remedy system is under new management. Under this new management we basically have no rights on the production box. We are supposed to tell Production Control what to put into production. The other systems that this management group manages deal mostly with having production control run scripts that are written by the developers. Remedy, though Panacea, could conceivably have a hundred or more objects to move between servers. I see this as a major headache moving forward.

So my question is this: how does your company handle moving workflow from development to production? I don't mean what tools, I mean your access to the production server.

PS: I asked this on another forum earlier in the year, so yes: if this question looks familiar it is.

Zeeter,

You may need to resort to "Fisher-Price" instructions w/ a Release Package. Basically, you document all the necessary files (.def, .arx, .csv, .rpt, whatever) that are needed and then the step-by-dirty-step (with lots of screenshots) of how they must move those onto the production server using the Admin, User, and Import tools. Of course, the more detail the better. This is for two reasons: 1) at some point in time, they may realize that you are better suited to the task than the prod control folks, 2) You have complete, tested (assuming you build the docs as you move all the code to a test/uat environment) documentation of how everything was supposed to be done, so if there are any issues after the release you can go back to them and find out where they went wrong.

It can be quite tedious, but effective. And, once you have a good template for the release instructions, it is not too bad to write up each time. In the past, I've done it something like this:

Section 1: Assumptions, caveats, Release #, etc.
Section 2: Packing list (include a .zip file w/ directories for Data, Defs, Reports, etc.) - list each file included in the release package
Section 3: Tools used
Section 4: Core Instructions
Section 5: Special Instructions
Section 6: Configuration Management instructions (if any) - This includes any Roles, Groups, Foundation Data, etc.
Section 7: Objects affected
Section 8: Test cases (separate docs for each change in the release, usually)
Section 9: Contact information

Anyway, that's a thought.

Two more thoughts on this, zeeter:
1) I always include a 'Release Notes' doc which summarizes all the changes going in, along w/ CRQ numbers, for customer reference and distribution
2) Obviously, there are other tools you might have them use, like Panacea or Migrator. That's up to you. I prefer keeping it simple and using the solutions that come bundled with the system... unless there's a good reason not to.

Enjoy & good luck!

Thanks Matt. It sounds like documentation is our best bet.

another option to dumb it down even more is using the administrator tool in command line mode to import a def package. Basically give them the files and commands to run and they don't have to use the UI.