Domanda

sto cercando un feedback da parte degli sviluppatori .Net che hanno esperienza con Aldon come una piattaforma di gestione del ciclo di vita. Stiamo seriamente pensando di utilizzare Aldon per la gestione del ciclo di vita tra cui il controllo di origine, automatizzato costruisce, ecc So che ci sono un sacco di altre opzioni là fuori, ma il nostro è primario / 400 negozio AS (con AS / 400 programmatori superando in numero sviluppatori .NET 6 a 1), e Aldon è utilizzato già dal nostro team iSeries. Il beneficio che stiamo cercando è avere una suite di gestione del ciclo di vita.

In sostanza, sto cercando di opinioni scritte da persone che hanno utilizzato Aldon e un altro set di strumenti (forse TFS, o una combinazione di SVN, Cruise Control, etc). Se avete lavorato con entrambi, avete una raccomandazione su se questa è una buona idea, o una cattiva idea? E 'ovviamente una grande scelta, quindi tutte le risposte sarebbe utile.

Modifica - Aggiunto

Non ci sono risposte o commenti ... e il mio primo distintivo Tumbleweed. Io non sono sicuro se questo è solo un brutto domanda, se nessuno utilizza effettivamente Aldon di gestire il proprio lavoro .NET, o se c'è solo nessuno usando Aldon che ha utilizzato altri prodotti e in grado di offrire un confronto.

Quindi, io sto offrendo una taglia per addolcire l'affare, e ampliando la portata della questione ... Se ci sono persone là fuori USO Aldon a tutti, si può fornire alcuna informazione su questioni che avete avuto, è è una buona suite di strumenti, frustrazioni, o trucchi, cose che ami, ecc?

Aggiunta -anche più Il nostro obiettivo primario è quello di avere un prodotto di gestire sia la nostra la nostra (soprattutto RPG) sviluppo AS / 400 e .NET. Se si dispone di un suggerimento per una diversa serie di strumenti, o hanno provato e deciso che non vale la pena, mi prendo la risposta pure.

È stato utile?

Soluzione

sto lavorando in un negozio simile al vostro - nel nostro caso, v'è una sostanziale base di codice legacy di codice COBOL iSeries, e un numero crescente di sistemi .NET - e gli sviluppatori .NET hanno fatto pressione con successo per utilizzare Subversion per il controllo di origine. Nel mio tempo breve per ammissione valutazione del prodotto, sembrava Aldon non era molto flessibile a tutti in aree come branching e di tagging, e ha un'interfaccia molto ingombrante e arcana. Dal momento che i cicli di vita del prodotto sono (MIS) gestite separatamente nel nostro negozio in ogni caso, che limitano l'uso di .NET di Aldon al controllo del codice sorgente unica, è stata una decisione semplice. Nel mondo .NET, Aldon è molto indietro rispetto gli strumenti open source standard in funzionalità e usabilità, e non ha alcuna speranza di competere con TFS. Nel nostro caso, il codice di gestione di NET al di fuori di Aldon ha sicuramente aumentato la produttività degli sviluppatori e diminuzione frustrazione.

Un esempio ... proveniente da un negozio di Subversion, stavo cercando di trovare il modo di creare un ramo sperimentale Aldon. Se è possibile a tutti, la documentazione ha fatto un grande lavoro di oscurare la funzione, e il nostro amministratore Aldon aveva mai incontrato il concetto. Tutto nel nostro negozio è bloccato stretto, con diritti di amministratore necessari per creare progetti, versioni, ecc Questo potrebbe essere utile dal punto di vista lifecycle management, ma dal punto di vista di uno sviluppatore cercando di ottenere il lavoro fatto, si tratta di un assassino. Non credo che la gestione del ciclo di vita e controllo del codice sorgente appartengono allo stesso software, e Aldon ha nulla fatto di dissuadermi da questo parere.

Altri suggerimenti

Credo che troverete qui nessuno lo usa. persone NET si dividono in due categorie - quelli che sono "a buon mercato" (vale a dire cercando di risparmiare sui costi) e poi in fondo si guarda o qualcosa di simile open source. E quelli che pagano molto, e la maggior parte di coloro che vanno con Team System - perché è ingtegrated in Visual Studio dal up fondo. AS / 400 è un Intermix piuttosto raro per sviluppatori .NET, così, alla fine -. Possibilmente sono solo fuori di fortuna

Io personalmente non sono sicuro mi sarebbe nemmeno la briga con esso. C'è molto di più per soemthing come Team System di monitoraggio fonte ecc - un sacco di buoni test funzioni, costruire in continua integrazione, ecc, e tutto ciò senza correre attraverso cappe per - bene -. Ottenere quindi un prodotto inferiore

Abbiamo riscontrato lo stesso problema al mio posto di lavoro, qualche anno fa, quando abbiamo iniziato il nostro primo progetto NET nel bel mezzo di un gruppo di sviluppatori di RPG. Al momento, abbiamo scelto di utilizzare un sistema di controllo del codice sorgente separato (Subversion) per qualsiasi cosa scritta in .NET (o per qualsiasi altra cosa che qualcuno volesse usarlo per). Ci siamo trasferiti tutti i nostri progetti (.NET e AS / 400) in Gemini per il tempo e difetti monitoraggio scopi. In sostanza, abbiamo scelto un singolo prodotto per gestire i nostri .NET e AS / 400 progetti ad alto livello, ma diversi strumenti per il controllo di versione, automatizzato costruisce, test automatici, ecc.

A distanza di anni posso tranquillamente dire che questo ha funzionato abbastanza bene per noi. Io davvero non riesco a pensare a tutti i problemi che questo ha causato - ma posso attestare il fatto che ha evitato alcuni potenziali mal di testa e cozzare di teste. Io credo che si avrà un tempo più facile ritrovamento (buono) NET sviluppatori per la scelta di un sistema di controllo versione ampiamente utilizzato. Non posso parlare per chiunque altro, ma per me l'uso di un sistema di controllo versione che ho mai nemmeno sentito parlare di sarebbe un po 'di una bandiera rossa in una situazione di intervista.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top