TFS per Java: cattiva idea?

Question

Stiamo considerando TFS per i nostri progetti basati su .NET e come piattaforma di gestione delle attività. Alcuni team si sviluppano esclusivamente in Java e sono abbastanza soddisfatti di SVN (Subclipse).

I nostri manager si avvicinò con le seguenti domande:

• Dovremmo migrare le squadre Java TFS come bene?
• Fa TFS (solo controllo del codice sorgente) gestisce bene i progetti Java?
• È un problema migrare la nostra base di codice Java e la cronologia da Subclipse a TFS?

Attualmente stiamo cercando di utilizzare TFS come unica piattaforma di controllo di origine per motivi di manutenibilità. Vorremmo evitare che i nostri tecnici IT supportino più sistemi.

Grazie

Answer 1

divulgazione completa, io lavoro sulla squadra che scrivere gli utensili Java per TFS in modo da prendere questa risposta come opportunamente :-) polarizzato

Per quanto riguarda il TFS è interessato - tutto il codice è creati uguali. Sono solo i byte nei file che esegue il check-in per il controllo della versione. Come tutti i sistemi SCM, non si cura in che lingua sono scritti i file.

Microsoft fornisce un completo, ricco TFS Plug-in for Eclipse (chiamato Team Explorer Everywhere). Ciò fornisce il controllo completo dell'origine, il tracciamento degli oggetti di lavoro, la costruzione, il punto di condivisione, l'accesso ai report ecc. In TFS da IDE basati su Eclipse. È scritto al 100% in Java e parla direttamente ai servizi web esposti da TFS.

Inoltre, forniamo anche un cross-platform command line client for TFS in modo da poter parlare con TFS dalla riga di comando del sistema operativo prescelto (Mac, Linux, Solaris, HP-UX, Aix ecc. Tutti completamente supportati).

Infine, se si dispone di strumenti scritti in Java che desiderano parlare con TFS, possono utilizzare lo TFS SDK for Java che è l'API completa utilizzata per creare l'integrazione di Eclipse e il client della riga di comando multipiattaforma ma impacchettato con esempi e frammenti e pronto per essere ridistribuito con le tue applicazioni.

Quando si tratta di costruire, ci sono un paio di scelte. Se vuoi attaccare al tuo attuale build server, è probabile che questo già stia parlando con TFS (fanno tutti i popolari server di sviluppo open source). Inoltre, Microsoft fornisce lo TFS Build Extensions che consente di eseguire build basate su Ant o Maven sul server Team Foundation Build. I risultati di compilazione (insieme a eventuali avvisi o errori) vengono pubblicati di nuovo in TFS insieme a qualsiasi dato di test JUnit se si eseguono i test JUnit come parte della build. Inoltre, puoi creare e gestire le definizioni di build nell'IDE di Eclipse e avere una posizione per gestire l'accesso ad esse ecc.

Quindi, il livello di supporto per Java è molto alto e Microsoft ha mostrato investimenti consistenti in questo settore. Abbiamo recentemente spedito alcuni TFS 2010 Power Tools for Eclipse e abbiamo anche distribuito le versioni di anteprima di Team Explorer Everywhere 11 insieme a Team Foundation Server 11 (siamo la stessa squadra all'interno dell'azienda).

Per importare la cronologia da SVN, equivale a importare la cronologia da qualsiasi strumento SCM in TFS (o TFS in qualsiasi strumento SCM). Hai un paio di opzioni. Puoi scattare un'istantanea e tagliare in un punto particolare (come una versione) o puoi migrare la cronologia. Per eseguire la migrazione della cronologia da SVN sono disponibili alcune soluzioni per i partner, tra cui una da Timely Migration con cui ho visto molti clienti avere successo.

Spero che questo aiuti.

Answer 2

Perché non utilizzare SVN per i progetti .NET? C'è qualche ragione per questo? Esistono più plugins per SVN in Visual Studio e una shell di Windows extension.

Answer 3

Mi piace molto la risposta di @Martin_Woodward, ma a mio avviso è troppo distorta, quindi aggiungo i miei 2 centesimi qui. Nella nostra azienda siamo in una situazione simile e la decisione (secondo me) dipende dal contesto. Posso vedere 3 diverse situazioni, e le decisioni possono essere differenti in ognuno:

1. Si sono per lo più in via di sviluppo di soluzioni .NET, e le parti Java sono integrati nelle soluzioni .NET.
2. Le soluzioni .NET sono indipendenti sviluppate dalle soluzioni Java e sono metà di .NET e metà di Java.
3. La maggior parte delle soluzioni sono sviluppate con Java, e solo una piccola percentuale è sviluppato con .NET

Sono d'accordo con Martin solo nel primo caso. Otterrai profitto dall'ambiente di sviluppo comune, dal controllo del codice sorgente, dal processo di compilazione ... I tuoi ragazzi Java impareranno le differenze con il controllo del codice sorgente TFS (ha un nome ??). E il tuo futuro apparirà luminoso ;-)

Se le soluzioni .NET e le soluzioni Java sono indipendenti l'una dall'altra, l'unico argomento per utilizzare TFS per lo sviluppo di soluzioni Java è il costo in funzione. E dovresti esaminarlo attentamente, se i risparmi per il funzionamento dell'ambiente di sviluppo solo TFS appesantiranno il costo aggiuntivo del passaggio dei progetti Subversion a TFS.

Nell'ultimo caso, sarebbe una decisione terribile passare con molte persone solo per avere un ambiente comune da sviluppare. È possibile integrare Subversion in VisualStudio (utilizzando ad esempio VisualSVN o altri plugin) e non si ha quasi alcun investimento.

La migrazione del codice sorgente, inclusa la cronologia, è normalmente un problema e dipende dalla fonte e dalla destinazione se ciò funziona correttamente. Abbiamo buone esperienze con CSV e SVN, ma nessuna (buona) esperienza con gli altri. Ma normalmente non è un problema, puoi usare i tuoi vecchi repository SVN (sola lettura) e semplicemente migrare l'ultimo milestone. Dopo qualche tempo, i repository SVN potrebbero essere lasciati in pace ...

Answer 4

Dopo un anno di lavoro su un progetto Java/JVM utilizzando TFS, vorrei dissuadere chiunque a farlo. Mentre TFS può essere considerato top-of-the-line per gli sviluppatori .NET, non troverai alcun Java Developer con alcuna esperienza con esso. C'è il plug-in per Eclipse e una porta per IntelliJ, ma ho avuto una fortuna terribile con entrambi, anche se suppongo che sia principalmente perché TFS non funziona come qualsiasi altro VCS che ho usato.

Sul nostro team, abbiamo stimato un sovraccarico del 10-15% a causa di TFS e complicanze causate da esso. Giorni di lavoro persi perché TFS ha deciso di sovrascrivere i file, giorni di problemi di risoluzione dei problemi causati da aggiornamenti TFS incompleti. Abbiamo fatto una filiale in 6 mesi perché l'intera squadra ha perso due giorni l'ultima volta che abbiamo fatto. È normale sentire la frase "Ho appena aggiornato con le ultime modifiche, puoi verificare che nulla scompaia nell'unione?". Invece di usare Jira, siamo bloccati a utilizzare il terribile problema di tracciamento in TFS, causando ancora più problemi.

Diversi sviluppatori del team hanno utilizzato git, sia standalone che git-tfs.Altri basta copiare l'albero dei sorgenti prima di qualsiasi attività 'a rischio', come l'aggiornamento o il check-in.

Ad ogni modo, non voglio raccomandare per una squadra che non ha esperienza con esso ...

Answer 5

Dopo 1 anno di lavoro con TFS/Java sono completamente d'accordo con Dusty J (Sì, TFS/Java è cattivo) e sono completamente in disaccordo con Martin Woodward sul grande supporto di Microsoft. Sebbene per il mio dovere di sviluppatore il TFS di Eclipse sia OK, i problemi riguardano i miei compiti di compilazione/rilascio.

Innanzitutto, questo plug-in Eclipse non consente la creazione di un ramo per più progetti contemporaneamente come in CVS/SVN. È necessario creare un ramo separatamente per ogni progetto. Quindi non possiamo mantenere gli stessi nomi di progetto nel ramo: è necessario modificare il nome di un progetto e dopo aver effettuato il check-out dal ramo per rinominare il nome originale. Vedi anche il mio post How to associate an Eclipse Workspace with TFS workspace?, non c'è modo di associare uno spazio di lavoro Eclipse con lo spazio di lavoro TFS. Pertanto, la mappatura per una cartella locale non può essere salvata; deve essere fatto di nuovo dopo aver aperto un altro spazio di lavoro di Eclipse per la creazione di filiali. E poiché la mappatura locale è la stessa, esiste la possibilità di cancellare una cartella locale con lavoro non salvato come ha scritto Dusty J.

Questa rimozione di file locali senza preavviso è una funzionalità terribile di TFS (vedere il post Why command get from a command line in TFS removes parallel projects?). Cosa pensa di Microsoft sulla possibilità di cancellare file locali con l'opzione regolare "Rimuovi mappatura locale" in Eclipse?

Quindi, nonostante i miei sforzi per apprendere TFS, trascorro ancora 10 volte più tempo per vari build rispetto al CVS che ho usato prima.

Answer 6

(Un altro dipendente di parte MS)

TFS formato una squadra di circa 18 mesi fa di concentrarsi esclusivamente sul rendere l'esperienza di Java grande in TFS/Team Services e su tutte le piattaforme. Sono in quella squadra e penso che abbiamo fatto un sacco di grandi progressi. Non sono d'accordo sul fatto che la storia del fine alla fine sia stata piuttosto brutta quando è stata posta questa domanda, ma penso che la risposta sia cambiata parecchio nell'ultimo anno.

Il mio team fornisce attività di compilazione e distribuzione per TFS nonché i plug-in per Eclipse e IntelliJ per rendere l'esperienza end-to-end il più completa possibile. Stiamo anche lavorando sodo per assicurarci di documentare come ottenere il meglio da TFS se sei uno sviluppatore Java.

Se si desidera maggiori dettagli, checkout http://java.visualstudio.com.

Grazie, Jason Prickett