Tidal Transporter

Question

Any one else using transporter to move between non-prod and prod environments?  Any "best practices" you can offer?

Answer 1

There should be a new version for 6X but I can't find anything on Cisco Site
Some of the Best Practices Above are 5.3.1 specific
Many issues are fixed in 6X like multiple concurrent connections
Transporter Best Practices 5/25/2011
Remember that Transporter uses a client connection license, so don’t leave it connected.
Create a mapping file for each environment that may be shared.
If you have two masters (one production and one test), you will have two mapping files, one from test to production and the other from production to test.
The mapping files reside on the network drive, along with the log files and saved transport selections.
Always prompt for a map update. This is set in the configuration.
Copy jobs to production as disabled if they are new jobs.
Manually enable the new jobs after transport to the production environment via the Client.
Existing jobs should always be copied in the same state that they are in production. If you copy an existing enabled job as disabled, the job will be removed from the existing schedules until you enable the job via the Client.
Save selections for jobs/groups that are constantly being transported. These files should be kept in the same location as the mapping files.
Archive activity logs. Make sure that the activity logs on the shared network drive are backed up. You will need to decide what your retention policy is and take action to implement it. Transporter does not maintain the logs after they are created.
Disable auto select dependencies for jobs with complex or many dependencies to enhance performance. All the auto select options should be configured in the off position. Turn them on only when needed. Remember to turn them off again after use.
To replace an existing job in the production environment, use the “includes duplicates” option in Transporter. This can be done in the configuration or by right clicking in the transport console when you have Jobs/Groups selected.
Avoid changing the effective date when transporting jobs unless you want all the jobs being transported to have a future start date. If a job is required to be scheduled in the future, use the TIDAL Client to schedule the job after the transport
Commit / rollback option in the configuration should only be used when no other users are creating jobs with the Client. This option may lock other users that are using the Transporter or the Client.
Transport your scheduling types based on the following sequence:
Calendar, Variables, Resources, and Job classes should be transported before all other items.
Actions must be transported before Events, with the exception of Job Actions. They can only be transported after the Job that they are putting into the schedule has been transported.
Jobs/Job Groups must be transported after all the other types have been transported.
Set restriction security on non-super users in the Client via the General Category in the Security Policy – “Move Jobs to Production” or “Move Own Jobs to Production”.
Transport Archive should be enabled in the configuration. This will enable you to back out a change if needed. This is done by using the Client to remove the newly transported job, and renaming the Archived job name and changing the parent group to the correct location in the Job Definitions.