CrossVista for build/source control..

, ,
1

Anyone else using this has some stories/tips/tricks to share?
We’ve found it’s been giving us a great amount of visibility of what’s changed between deployments and people are forced to use source control.

Using with 8.2 so have been finding a few things along the way, but can’t really imagine going back to the dark old days now.

The advantages as I see it:

  • ability to diff changes in a meaningful way
  • all code is automatically in source control in order to do a deployment
  • history of changes (as in actual proper source control)
  • more powerful config rewriting than WmDeployer (e.g. running regex or xpaths across various elements or file level re-writes)
  • environment synch check for admin elements
  • visibility of what is deployed where
  • can avoid having many manual steps
  • means we can get away from doing patch deployments (I hate patches with a passion because it’s near impossible to set up a new environment easily)

Like any powerful tool we have had people do crazy things (e.g. deploy server elements) but the vendor was pretty quick to add in improvements to help prevent that (e.g. deselecting all the admin elements by default so people would have to explicitly add things back in).

Documentation leaves a bit to be desired at times, but got clarity from their support guys when needed.
Major work getting going was spending a bit of time coming up with naming standards etc and a user guide to train staff on how to use it. Then getting people familiar with the terminology.

Some tricks relating to how to do certain things (e.g. “I forgot a package” or “I want to remove that ACL from deployment”) but once you’ve got those worked out it’s easy to do. So far I haven’t had any teams resort to patch type deployments, which is good: it used to be the standard way of deploying (and that scared me when I came on board). The work is in undoing the years of reliance on manual deployment steps (e.g. updating passwords/server addresses on each node type stuff).

All in all I think a good replacement for manual source control and dodgy WmDeployer.

So how about other people?

2

One thing we haven’t done much of is the automation, so if anyone’s been doing that stuff I’d be interested to know.

Currently our deployment to cluster = deploy to node 1, then once that’s verified use sites to get to rest of the nodes. So nothing too sophisticated…

3

Noticed another thread from a while back:

[URL=“wmusers.com”]wmusers.com

Was 1.5, we’ve been using 1.5B and there’s 1.6 on the way.

4

Excellent stuff. We did an eval last year and the items you’ve listed are all compelling. They are really, in my opinion, the minimum set of things needed to do version control and environment management effectively. The VCS integration feature of IS and Developer is, IMO, all but useless. The only thing it does is store (some of) the artifacts in a VCS. There is some value there but not much.