• Replies 5 replies
  • Subscribers 338 subscribers
  • Views 147 views
  • Users 0 members are here
Related

LIVE to TEST Overwrites

Matt Gonzales
$organization

Forgive me if I've asked this question before or if it's well-trod ground by this point, but what is the recommendation for a common scenario (for us, at least) wherein a contractor works with us to develop custom screens in our TEST database but ends up losing their work when a LIVE to TEST copy happens. Surely there's a way to keep that information saved that doesn't involve simply re-entering it by hand - especially since the contractor may charge additional money for the time it takes for them to put that code back. During rollover, we typically do LIVE to TEST copies every other day until it's all worked out. I know this may not be very efficient, but I'm working on that one, believe me.

Anyway, I hope someone can point me in the right direction, even if it's just giving me a proper keyword search for the issue.

Thanks in advance, Tessiturians.

  • $organization

    This is a super typical question in my experience.  We regularly have the conversation before Live to Test Copies.  Do we have everything out of Test System?  What can be moved to Live Fast, so we don't lose it and don't have to manually copy it back into Test?

    If we come up with a good way to do this, I think this would help all.    

  • $organization

    We maintain a Dev system in addition to a Test system.  Our developer(s) also maintain personal Infomaker and Visual Studio solutions, and then when things are ready to Test, I am informed to pick up their custom objects and merge them into the Test solutions.  Those are re-deployed with each Test refresh.

  • $organization

    Hi Matt,

    Here are some things we do to help manage work like you are describing:

    • Similar to what Nancy described, we have additional Tessitura test environments used for various purposes, including development. We do this so that we can support a project that requires a stable environment over a period of time.
    • I try to get those involved in developing a solution (including me) to track what they are doing so we can find a way to deploy those changes as quickly as possible.
    • I use database schema and data comparison tools to try and identify differences between one of our test environments and live. The best tools I have found for this are Red Gate SQL Compare (for schema comparisons) and SQL Data Compare (for data comparisons). Those tools can create deployment scripts based on the differences, which can be useful. Visual Studio also has tools for this built-in (It may require data tools to be installed). You can find these in Tools - SQL Server - New Data Comparison and New Schema Comparison. They aren't as robust as the Red Gate tools, but are free.

    For a data comparison tool, you'd want to select tables to compare. For example, if the work involved adding or modifying system tables, you could focus attention on the TR_, LTR_, etc type of tables.

    A key thing, in my opinion, is having an environment that you can keep relatively stable for the duration of a project so it isn't impacted by scheduled or routine Live to Test copies. But if that isn't feasible, some of those tools could still be used to help identify the changes before a LIVE to TEST refresh is done. I hope this helps.

  • $organization

    We don't run frequent Live->Test copies, but we almost always have something (often lots of somethings) in development, so it's always an item to check in on before running the Live->Test.

    For most users who are planning out some new configuration (i.e. whatever is being developed is just Tessitura settings) that is mostly insurmountable (without, say, a third environment, as Nancy suggests).  But for a developer, all my custom work is always saved in files so that it can be quickly re-deployed.  A contractor ought to be doing that, and be able to work around your Live->Test schedule, assuming they've been given it.

    I've learned over time that even things like new attributes that I'm working on are worth having their creation scripted out into a file for this purpose.

    Depending on who performs the Live->Test (RAMP for us) and how, you may need to take steps to preserve any Infomaker library files under development.

  • $organization

    Ideally, the developer is using a one-step deploy that can be run at any time, and works the same way when aimed at the TEST system, or LIVE for deployments and updates. Frankly, this is not particularly easy to do (and custom report setup XML doesn't play nice with this), but I think it's worth developing the skills, and holding 3rd-party contractors to that standard.