Anyone already used Team Server?

, , ,
1

Hi All,

Is there anyone using Team Server (CrossVista)?
I would like to share information about it:

-Is this product a reliable Configuration Management System?
-Any objective opinion about it? Pros-Cons?
-Any concurrent product?
-What’s about traceability regarding Requirements/Change Requests?
Thank you.

2

Hi Halikri,

Yup me has been using team server for a while now. to your queries please find my answers in red

-Is this product a reliable Configuration Management System? -yes its relaible from version 1.5 onwards. It is compatible with any VCS in the market like subversion and CVS. The performance was bad pre 1.5 as there were loads of bugs. Had found a few myself.
-Any objective opinion about it? Pros-Cons?
[COLOR=Red]-Pros

  1. Its is pretty good in how you can deploy your deployment sets. You can set domain paramaters on the fly e.g your configurations in QA and PROD might be different it can help you do that while deploying.
  2. Doesnt make your IS’es talk directly. It used a Subversion repo to deploy sets across different IS’es across environments.
  3. You can revert to any deployment set which has been done on TEAM so you have total control over deployment sets.
  4. Good user accountability, i.e. you can give accesses like Developer/Admin/Operator/Auditor based on your need.
  5. If you have a clustered environment you can do site comparisons to find differences in configurations directly.
  6. Auto deployment feature is cool…i.e you can schedule your deployments for a future period and forget about it. Cross Vista will do it in ease.
    lot more are there actually
    -Cons
  7. The user management is very bad and has much to be desired.
  8. Additional administration overhead is required to Administer Cross Vista TEAM.
  9. Product is relatively new so there are a few bugs that keep propping up.
    [/color] -Any concurrent product?
    none that i know about.
    -What’s about traceability regarding Requirements/Change Requests?
    This is not a Change System. It is a VCS with Release management capabilities revolving around web Methods.

Let me know if you need more information n the same.

Reg,
Sam…

3

Even i have used Team server client. I am not much impressed with Team Server. After Reading above post, may be i used older version of Team Server.

4

Hi mangatrai,

That definitely seems to be the case. As 1.5B is much better than 1.4. Try giving the new one a shot and you ll see how good an allay it can be.

sam…

5

Hi Sam,

Just wondering what is the deployment requirement on developer front. Reading some of the docos I can see that there is obviously a need for a central server running Team Server.
Can you share some of your experience of how to divide up the development streams for the dev teams? What have you found to be most effective? It seems to be relying quite heavily on logically defining a project and subsequent releases. How well does that marry up to when you having to support multiple products (developed in webMethods)?

any insights and advice are appreciated.

cheers,

Paul

6

Hi Paul,

Thats a lot of different streamed open ended questions… :slight_smile: Let me start one by one…

Just wondering what is the deployment requirement on developer front. : There is absolutely no development requirement from any one’s side to implement TEAM, as its just a bunch of simple easy to remember configurations and you are good to go. The use of a central admin server is a good practice across webMethods implementations involving a large group of servers if need to be run in a cluster or a stand alone config. So TEAM just leverages that platform. As simple as that it requires 2 packages to be installed on the Central Admin server and 1 package each on any server which you need to connect to…

Can you share some of your experience of how to divide up the development streams for the dev teams? : Well the division of your streams are pretty much implementation and process dependent which are prevalent in your organization. Normally as a best practice we would divide our environments as DEV/QA/UAT & PROD. Each will have their instances of CrossVista TEAM and have separate sub-version repositories to secure the code and thereby making the code completely versioned. You can check out the training videos on CrossVista.com for the ALM (Application Lifecycle Management) that will answer most of your questions.

What have you found to be most effective? Overall the package is pretty neat, the versioning and deployments were a great boon specially if you have very large scale integrations involved. Also one imp feature was the Operational Releases that came in handy to debug clustered servers. There is a video describing the same on the site do check it out.

It seems to be relying quite heavily on logically defining a project and subsequent releases? : Yes you are correct, but you need to understand one thing the approach that CV has chosen has been done after a good amount of work, atleast i feel that as the approach pretty much covers all aspects of a good Release/Configuration/Change/Versioning tool. So it works. But then again CV is an enabler how you enable its for you to decide.

How well does that marry up to when you having to support multiple products (developed in webMethods): Well as of now most of the configurable components are covered in CV like TN/Developer/IS/BPM etc. For the newer product lines like ARIS/AppLinX etc we need to see how they shape up. Latest i heard from Dan was that they have integrated Remedy with CV and now it allows to do ticketed work as well which will be very cool…

Hope i answered your queries. Lemme know if you need more details on the same.

regards,
Sam…