Impostazione di un ambiente di sviluppo

Lo hai già fatto prima. In realtà ci vivo ancora. In genere hai una buona idea di dove ti stai dirigendo - la maggior parte della gente che fa questo usa a malapena il controllo del codice sorgente. Un sacco di esattamente cosa usare dipende da quale pila (s) si utilizza. Puoi condividerlo?

In ogni caso, esegui il tuo elenco:

1. SCM: dipende davvero dall'ambiente. Se sei su Windows, Mercurial tende ad avere molto più senso in quanto non sei un cittadino di 2a classe. io prendere seriamente in considerazione l'utilizzo di una soluzione ospitata qui se il tuo il software non è troppo top secret e hai una solida larghezza di banda da prendere vantaggio di esso. Un altro lato di questo - SVN non è poi così male in scenari interni in cui sai di avere connettività e il controllo centrale ha senso E ha il vantaggio di essere molto più facile da digerire per chi non lo sapesse. Posso portare il mio dipartimento artistico a un po 'usare SVN. Buona fortuna con git.
2. Monitoraggio dei bug / documentazione: li sto raggruppando insieme perché lo farei generalmente sostengono che li volete nello stesso sistema. Per piccole squadre, la scelta migliore IMHO è Redmine (o Chili dipende da quale forcella vuoi tornare). Entrambi gestiscono bug e fanno wiki / discussione tipo roba. Inoltre, è facile da collegare da bug alla discussione o wiki e viceversa. Possono anche facilmente prendere biglietti via e-mail e collegarsi a LDAP, il che lo rende piuttosto facile per far sì che i tuoi utenti finali inviino biglietti rintracciabili anziché email casuali alla persona sbagliata alle 2 di notte di domenica. Oh, e questo parlerà anche con il tuo SCM.
3. Non hai menzionato l'integrazione continua, ma direi che lo è forse più importante di qualsiasi cosa qui, ma il controllo del codice sorgente ti mantiene onesto In una certa misura, cosa usare dipende da cosa sei costruzione, ma in generale l'opzione migliore là fuori è IMHO TeamCity . L'SKU gratuito probabilmente funziona per la maggior parte degli usi interni come 20 progetti e utenti sono in genere più che sufficienti. La bellezza di è così inquietante, facile da configurare, è spaventoso - puoi andare da zero a qualità continuamente integrata in 5 minuti. 4 di che vengono spesi guardando l'installer andare.

L'altro punto di vista sarebbe chiedere ai tuoi sviluppatori cosa vogliono usare. O impostare una sorta di budget di fondi per strumenti fangosi per loro. Le cose nuove si aprono continuamente ed è molto, molto app / piattaforma / lingua specifica ciò che le persone vogliono.

Posso suggerirti Redmine .

Redmine è un'applicazione web flessibile per la gestione dei progetti, che supporta queste funzionalità:

• Supporto per più progetti
• Controllo dell'accesso flessibile basato sui ruoli
• Sistema di tracciamento dei problemi flessibile
• Diagramma di Gantt e calendario
• Notizie, documenti e amp; gestione dei file
• Feed & notifiche email
• Per wiki del progetto
• Per i forum di progetto
• Monitoraggio del tempo
• Campi personalizzati per problemi, time-entry, progetti e utenti
• Integrazione SCM (SVN, CVS, Git, Mercurial, Bazaar e Darcs)
• Creazione del problema tramite e-mail
• Supporto dell'autenticazione LDAP multipla
• Supporto per la registrazione automatica dell'utente
• Supporto multilingua
• Supporto per più database

Come puoi vedere dall'elenco delle caratteristiche, è un ambiente di sviluppo completo che può essere integrato con diversi programmi SCM, se ti senti a tuo agio con Mercurial puoi usare Mercurial perfettamente integrato con Redmine.

Personalmente sto usando Redmine da 2 anni e non ho mai trovato qualcosa di simile in questo settore, è semplicemente il migliore!

Per il controllo del codice sorgente, ti consiglio di attenersi a SVN finché non avrai bisogno di DVCS. È facile da imparare, ha un sacco di supporto per la comunità sia per * nix e Windows. E non ti lega. Puoi trasferirti facilmente da lì a Mercurial o Git quando ne hai bisogno.

Se puoi permetterti lo stack completo Atlassian , o almeno Jira e Confluence, ti suggerisco di fare il miglior investimento possibile rendere. Se non è possibile, allora Trac è probabilmente la soluzione migliore (e ha Wiki integrato).

Vorrei anche raccomandare Jenkins come uno strumento CI accurato ed estensibile, sebbene il suo supporto per lo stack .NET sia un po 'discutibile, se stai seguendo questa strada.

Infine, suggerirei di ottenere una copia di Consegna continua per una massa di ulteriori consigli.

Questo è il mio stack preferito per lo sviluppo privato in questo momento:

Controllo versione: Git

Gestione del repository Git: Gitorious

Wiki della documentazione: MoinMoin (ottimi plugin, facile da hackerare, sviluppatori reattivi)

Integrazione continua: Jenkins

Gestione build / distribuzione: Maven 3 (utilizzato anche per progetti non Java)

Gestione artefatti: Archiva

Gestione agile: Tracker pivotal (tracciamento dei bug per ora, ma serve qualcosa di più specifico per il team addetto al controllo qualità)

Monitoraggio dei bug: Decidere su questo, deve avere una stretta integrazione con Pivotal Tracker)

Queste non sono le cose più fondamentali, ma se stavo partendo da zero, guarderei sicuramente:

Cloud - qualcosa come Amazon Web Services per il provisioning e l'esecuzione degli ambienti.

Devops: automatizzazione e creazione di script per la creazione di ambienti in modo ripetibile.

Vagrant & virtualizzazione - accelerare la fornitura di ambienti di sviluppo.

Consegna continua: configurazione di sistemi, processi, architettura, ecc. in modo da poter automatizzare e velocizzare le pubblicazioni e la consegna con tempi di fermo minimi.

Questo tipo di cose sembra ortogonale a uno sviluppo, ma nella mia esperienza, può richiedere molto tempo e fornire un sacco di valore se si fa bene. È anche molto più facile da fare se si inizia con una lavagna vuota.

Per quanto riguarda il controllo del codice sorgente, penso che tu sia sulla strada giusta.

Il problema con Defect Tracking Software è che non esistono praticamente FOS adatti disponibili. Jira è abbastanza buona ma non sono a conoscenza dello schema dei prezzi. Vorrei suggerire di dare un'occhiata a FogBugz che sembrano abbastanza accessibili. Inoltre, non l'ho provato personalmente ma conoscendo altri prodotti di questa azienda, potresti provare YouTrack .

Altri hanno già suggerito l'integrazione continua. Questa è una strada da percorrere, ma andrei anche oltre: potresti pensare a Consegna continua .

Source Control - Mercurial or Git - I am personally leaning more towards Mercurial based on my research and the fact that Mercurial appears to be easier to setup in our environment.

Per il controllo del codice sorgente, devi pensare a come stai usando il controllo del codice sorgente. Mercurial HG è davvero buono, se i tuoi sviluppatori sono fuori sede. Il controllo del codice rende anche più semplice l'unione.

Tortoise SVN è buono altrimenti. Inoltre, se stai sviluppando in .net e hai un po 'di soldi, cerca la versione VS Team. Se si esegue un gran numero di database con le stored procedure, la versione di Team ha il debug SQL. È veramente carino. Inoltre puoi ottenere svn integrato con VS, ma non è gratuito.

Bug Tracking - I'm at a loss here. I have used Bugzilla in the past, but, it makes me cringe when I use it.

Bugzilla, è molto utile e funziona bene nel mio parere arogant.

Documentation - MediaWiki, Screwturn Wiki, Atlassian (of course, this costs money so that is not ideal)

wiki è un wiki, la documentazione diventa obsoleta. Se hai un team di quattro sviluppatori, probabilmente stai facendo fare loro così tanto lavoro che non avranno il tempo di documentare molto. Ma se vuoi tenere un wiki con tutti i mezzi, usalo. Suggerirei chatter di forza vendita per gestire la comunicazione / documentazione. È più di un sito collaborativo. Non so come configurarlo ma per le persone non tecniche per comunicare con una tecnica è funzionante e l'interfaccia utente è semplice. Ti dà una sensazione di facebook.

Inoltre non hai menzionato il test dell'unità. Raccomando la custodia Nunit che è possibile configurare per eseguire i test unitari attraverso la console, se si desidera impostare una casella di compilazione per le build notturne. Di nuovo questo è l'ambiente .net.

Anche test di regressione. Credimi, ti risparmierai un sacco di mal di testa e un miglior controllo sulla morale del team, se hai uno strumento di test di regressione o offri ai tuoi sviluppatori l'opzione e il tempo di crearne uno per il tuo software. Non te ne pentirai e avrai i tuoi sviluppatori con te più a lungo. Di nuovo questo è nel mio parere arrogante.

Nel mio posto di lavoro precedente, stavamo usando Trac (bug tracking, project planning, documentation) con Subversion - si integrano abbastanza bene. Non sei sicuro di come si integri con Hg o Git.

Posso parlarti di tre configurazioni di sviluppo che conosco (la mia e due dei miei amici).

Impostazione personalizzata (molti programmi sono di buon livello):

• Sublime Text 2 per tutte le modifiche di programmazione / testo. È multipiattaforma e ha "strumenti di compilazione" per diversi tipi di programmi (il mio unico problema è con Java, non ha una corsa java, solo un compilatore java) ed è completamente personalizzabile quando si tratta di frammenti (testo auto-espansione), combinazioni di colori e strumenti di costruzione (il mio reclamo su java è annullato qui, perché potrei semplicemente crearne uno io stesso).

• Se mi sento in linea di comando, uso nano per il mio editor di testo.

• Git per tutti i controlli di versione. Ho una sezione di repo 'privata' sul mio sito web per progetti personali che non voglio che le persone trovino o facciano problemi con facilità. Uso GitHub per repository pubblici e progetti che non mi dispiacerebbe ricevere aiuto da altre persone.

• Terminale (per installazioni Linux) e Prompt dei comandi (per installazioni Windows). Controllo Git attraverso il terminale e non una GUI, e lo uso anche per eseguire i miei programmi java. La mia unica vera lamentela è che devo usare i percorsi completi su Windows perché non ha collegamenti simbolici, ma è solo Windows. Personalmente preferisco bash over dos.

• Per la documentazione di solito lo scrivo nei programmi o scrivo i miei documenti per questo.

Impostazione di Friend One (molti programmi sono di buon livello):

• Notepad ++ (Windows) o Gedit (Linux) come editor di testo. Entrambi sono gratuiti ed estensibili, entrambi hanno un plugin api e alcuni buoni plugin (mi piace il set che viene fornito con Gedit-Gmate). Hanno anche entrambi gli "strumenti utente" o comandi scorciatoia che puoi eseguire per eseguire comandi personalizzati sui tuoi documenti aperti (o anche solo comandi personalizzati per il sistema).

• Git per il controllo della versione. Praticamente la stessa configurazione di me stesso, utilizza anche il terminale / prompt dei comandi / GitBash.

Impostazione di Friend Two (Un solo programma per regolarli tutti):

• Eclipse per tutto. Eclipse è l'unico programma che apre.

• Tutta la documentazione viene eseguita in linea con il codice, generalmente utilizzando docblock.