Originally posted by: andyzz411

Hi

We are using version control(TFS).We installed plug in for eclipse in DEV.How to move code from DEV to TEST as we will not install version control in TEST.

Originally posted by: jvanboga

I guess I'm unsure I'll really answer your question but I'll try... 

Your map code should be relatively invisible to the environment.  Use environmental variables if the test and dev reside on the same machine.  If they reside on diff machines then your machines should mirror each other as much as possible, else, again, use variables.

Things that will require recompiles when moving a compiled/run map from one environment to another are database input and output cards.  If you are running a map and an input card defined as a DB input you'll need to recompile between moves.  The same is true for similar output cards.  Database queries from within a rule are not subject to the same restriction.

Originally posted by: Laurent(Satisco)

The code you need to move is compiled maps (and maybe systems), so a simple script should be able to do this, may be using FTP depending on the network layout.

If your project is complex (more than a few maps), the a script (or Ant script) is deifnitely the way to go

Recompiling will not be necessary if WTX is used "stand alone", even if the DB is used, provided the MDQ and/or resource registry are used.

Originally posted by: jvanboga

I'm not sure about the most recent version of WTX but depending on how you write your maps recompiles are required between environments.  Certain items, described above get compiled into the runmaps.  Complexity doesn't matter.

Originally posted by: Laurent(Satisco)

It's still the case that the map gets compiled FOR the target platform, but even if the MDQ is also compiled into the map, everything can be overridden at runtime.

The most common case (at least for me) is that the compiled map embed the SQL query for input, but I do override connect string at runtime.

Recompiling would mean retesting, as the map you'd deploy is not exactly the same you tested.

Originally posted by: jvanboga

Correct, most things can be overridden.  That's why we use environmental variables, which is what you are doing.  Not everyone designs their maps that way, especially people just learning WTX. 

If we need to retest a compile that doesn't involve a change of code we have an issue.  

Generally, though, I think we are on the same page.  Been an interesting discussion.

Originally posted by: Dan411

Thanks for your reply.

We have around 150 maps in 8 projects.We are using only windows environment.What kind of scripts  we can use to migrate all the mmc's  and .msl's from DEV(abcd name) environment to Test(xyz name) environment.

Originally posted by: Laurent(Satisco)

I'm not sure I understand your requirement. If it's only to move the files, any file transfer protocol will do.

It may be worth having a look at IFD's "deploy scripts", if TEST is accessible from DEV via FTP, as it will build/deploy all files in one operation (from the GUI or from a command line).

Originally posted by: jvanboga

You really need to look at your environments and determined the best way to work your deployments.

You can use batch scripts if recompiles aren't necessary.  You can also use IFD.  In our environment we use both. 

Essentially we have DEV, SUP, QA, UA and Prod.  The development team has access to Dev and SUP.  It stages code for the other environs. 

When Launcher is managing the events everything is always staged with IFD.  If we are using our other scheduling tools the developer can stage however they wish.  The nice thing about IFD is that it provides you with an opportunity to override card and map settings on deployment (those that aren't overridden by other maps and command server scripts.)  It also warns you if there are obvious issues with deployment paths and you document the systems as you go.

The down side to IFD is that you still need to manually deploy batch files, sqlldr scripts, parms, DBID files and such.  Some of these files are not updated as frequently and others can be updated to avoid code changes and still others can be created dynamically so it won't matter.