Novembre 2015

Volume 30 Numero 12

Il presente articolo è stato tradotto automaticamente.

Microsoft Azure - Gestire il debito tecnico con SonarQube e TFS

Da Cesar Solis Solis | Novembre 2015

Debito tecnico è il set di problemi di un'attività di sviluppo che rendono lo stato di avanzamento nel valore del cliente inefficiente. Minano la produttività eseguendo codice difficile da comprendere, fragile, richiede molto tempo per modificare, difficile da convalidare e crea il lavoro non pianificato che blocca l'avanzamento. Debito tecnico SAP a livello di attendibilità di un'organizzazione a causa dei costi di assistenza clienti elevata e, infine, una combinazione di questi problemi produce problemi maggiori.

Debito tecnico è pericolosa. Inizia piccolo e aumenta nel tempo tramite l'accelerazione delle modifiche e la mancanza di contesto e disciplina. È possibile materializzare da altra, anche per un progetto considerato come "pulito", a causa delle modifiche in caso di progetto. Codice prototipo prodotto per il mercato statunitense, ad esempio, potrebbe essere proposti per debito internazionale, creando immediatamente alla verifica della localizzabilità. In alternativa, con l'evolvono di tecnologie, l'applicazione potrebbe non stare.

Debito disponibile in varie forme, inclusi i problemi rilevati tramite analisi del codice, codice duplicato, complessità del codice, non è sufficiente test, test sovrapposti e attendibili e e "architettura talmente".

I problemi principali affrontati dai team di sviluppo nella gestione dei loro debito tecnico includono:

  • Comprendere e identificare il debito e dove si trova nel codice.
  • Valutare il costo della riparazione e il costo della riparazione non. Correzione di un debito tecnico ha un costo. Anche ripristinarlo non ha un costo, che è ancora più complesso per valutare e può essere più grande.
  • Attuando criteri incentrate sulla prevenzione debito dal recupero peggiore e la gestione verso il basso.
  • Esporre agli sviluppatori di debito necessarie per soddisfare i criteri in modo che non è eccessivo, in modo che possano possibile affrontare, come parte integrante del processo di sviluppo quotidiane e non considerano enorme molto tempo e fastidioso lunga e complessa.
  • Rilevamento debito nel tempo per assicurarsi che sia tendenze nella direzione giusta e che soddisfano i criteri definiti.
  • Debito aggiornando in modo efficiente e automaticamente come possibili.

Quindi, deve essere gestito tale debito, non necessariamente eliminato e, pertanto deve essere misurata. Quando gestito verso il basso, dare priorità tra le altre nuove caratteristiche e funzionalità desiderata. L'impatto deve essere misurata anche, così come viene misurato l'impatto finanziario di acquisire un prestito.

È necessario essere consapevoli delle decisioni che potrebbero aumentare debito tecnico durante lo sviluppo. Deve essere in grado di misurare i miglioramenti ottenuti gestendo effettivamente un debito tecnico. Questo è importante per giustificare i proprietari del prodotto (client, gli utenti, responsabili e così via) investimento.

Soluzioni, ad esempio SonarQube da SonarSource collaborare con Visual Studio Team Foundation Server (TFS) per fornire le strategie per facilitare la raccolta dei dati e presentano in modo che consente di gestire e ridurre il debito tecnico. SonarQube è una piattaforma open source per la comprensione e la gestione di un debito tecnico.

In questo articolo ci concentreremo su un metodo di misurazione e gestire attivamente un debito tecnico. Chiamato valutazione della qualità del Software basato sulle aspettative del ciclo di vita (SQALE), che è un metodo Apri origine incentrato sugli attributi non funzionali qualità di una codebase software (bit.ly/1JQ96qT). Il metodo SQALE è stato sviluppato da Inspearit Francia (noto in precedenza DNV ITGS Francia).

In base a un post di blog SonarSource debito tecnico è simile a una perdita di acqua home (bit.ly/1N0Y4A9). Quando si dispone di una perdita di acqua, a casa, cosa si collega in primo luogo, la perdita o sfruttare pavimento? La risposta è semplice e intuitivo: Si collega la perdita. Perché? Poiché qualsiasi altra azione sarà inutile; sarà solo una questione di tempo prima che la stessa quantità di acqua è tornato sul pavimento.

Con un debito tecnico, "riparare la perdita di" significa creare lo stato attivo in codice "new". ovvero, il codice che è stato aggiunto o modificato dopo l'ultima versione o l'ultimo commit/archiviazione.

Implementazione di SonarQube e TFS

Figura 1 viene illustrata un'architettura di riferimento per un'installazione di enterprise di TFS e SonarQube, vi è una Guida dettagliata sulla capacità, progettazione, implementazione e funzionamento di TFS locale e in Microsoft Azure infrastruttura come servizio (IaaS) nella "Guida alla pianificazione TFS" e "TFS in Azure IaaS Guide" che può essere scaricato dal sito CodePlex per Visual Studio ALM Rangers (aka.ms/treasure5). Questa architettura e la relativa implementazione vengono indirizzate verso il supporto di livello enterprise prendendo in considerazione le funzionalità di disponibilità elevata nel livello dati tramite un cluster di database e nel livello applicazione con una farm.

Team Foundation Server Reference Architecture, tra cui SonarQube
Figura 1 Team Foundation Server Reference Architecture, tra cui SonarQube

Una distribuzione a server scalabile SonarQube può essere ottenuta mediante l'impostazione più SonarQube server, in base ai singoli team o dalla tecnologia prendendo in considerazione quanto segue:

Un database SonarQube può essere installato in un'istanza del cluster di database che fornisce un modo sicuro per gestire i servizi a elevata disponibilità.

Analizzatore SonarQube (plug-in) implementa un modo per carichi di elaborazione dei dati di analysis server scalabile nel database SonarQube.

Il database e gli analizzatori devono trovarsi nella stessa rete. SonarSource lavorando refactoring SonarQube (versione 5.2) in modo che in un'architettura a tre livelli, che renderà obsoleto questo vincolo.

Tutti i computer, database, server Web, analizzatori, deve essere ora sincronizzata.

Prerequisiti per l'Hosting SonarQube e TFS in Azure

Per configurare un ambiente TFS e SonarQube in Azure è necessario disporre di una sottoscrizione di Azure con sufficiente credito rispetto alle dimensioni dell'ambiente che si desidera creare. È possibile utilizzare la Guida alla pianificazione di TFS (bit.ly/1JzfVJK) per decidere le dimensioni delle macchine virtuali (VM). La Guida fornisce anche suggerimenti sui modelli di autenticazione, ad esempio autonoma, opzioni di trust unidirezionali e dominio esteso. Un'ottima funzionalità di Azure che può aiutare ad accelerare la creazione dell'ambiente è il modello di TFS VM preimpostato disponibile, come illustrato nella Figura 2.

Modello di macchine virtuali disponibile in Microsoft Azure
Figura 2 macchine virtuali modello disponibile in Microsoft Azure

Configurazione di rete deve essere selezionata in base alle esigenze per la protezione dell'accesso esterno ai livelli interni dell'architettura di TFS. Un modo per estendere l'infrastruttura aziendale e ottenere elasticità del cloud, è necessario esaminare i diversi modi per connettere Azure locale tramite VPN. La guida descrive le procedure consigliate e suggerimenti sulle prestazioni che sono utili nella configurazione dell'ambiente TFS in Azure. SonarQube richiede che il database e analizzatori devono trovarsi nella stessa rete.

Durante la pianificazione per l'installazione, attenersi alla procedura consigliata:

  • Determinare l'idoneità IaaS di Azure. Cloud computing offre capacità di elaborazione come servizio, consentendo l'accesso alle risorse, ad esempio calcolare energia, rete e archiviazione. Decidere se i vincoli sono accettabili e se è presente un valore aggiunto.
  • Pianificazione di TFS. Utilizzare "TFS pianificazione ed emergenza prevenzione e ripristino Guide" (bit.ly/1JzfVJK) per determinare l'architettura server ottimale per le proprie esigenze.
  • Azure IaaS mapping. Eseguire il mapping per la configurazione macchina virtuale di Azure più vicina in base al costo e scalabilità.
  • Controllo della piattaforma Azure. Definire l'account, sottoscrizioni e la proprietà di amministrazione e report per soddisfare i requisiti di controllo dell'organizzazione. Consente di definire chiaramente le responsabilità e.
  • Pianificazione della rete. Definire la rete, che comprende i requisiti in locale, segmenti di indirizzo di rete, raggruppamento di affinità, la risoluzione dei nomi, tunneling Azure e monitoraggio.
  • Pianificazione dell'archiviazione. Definire la strategia di archiviazione mediante archiviazione locale o archiviazione Azure.
  • Convalidare. Contattare un esperto in materia Azure dalla community Microsoft o di Azure (bit.ly/1fVTgz0) e convalidare i piani prima del commit manualmente. Verificare l'ambiente pianificato è tecnicamente e finanziariamente vitale e può essere gestito.

Come l'intenzione di questo articolo consiste nel configurare un server SonarQube per scopi di valutazione e dimostrazione, passaggi aggiuntivi non vengono indicati di seguito. Se si intende o il provisioning di un ambiente di produzione o di una migrazione da una esistente, è necessario rivedere gli altri passaggi nella Guida per un piano completo. È inoltre disponibile un elenco di controllo di distribuzione nella Guida da seguire per una corretta installazione.

Architettura e installazione esercitato fanno riferimento a IaaS di Azure qui si basa sul modello di prova in dettaglio in "TFS in Azure IaaS Guide," che può essere utilizzato per l'implementazione di esempio prova complementare. Mentre la Guida contiene procedure dettagliate per l'impostazione dell'ambiente TFS POC, non esiste alcun vincolo utilizzando le stesse istruzioni con il proprio ambiente di prova o di produzione di uno.

Requisiti di installazione SonarQube

È consigliabile utilizzare la stessa istanza di SQL Server IaaS per l'installazione di SonarQube, solo che si occupa del specifici requisiti di configurazione di SQL Server quando si crea il database SonarQube. Il "SonarQube installazione manuale per Team Foundation Server 2013 singolo ambiente Server esistente" (bit.ly/1itxhS9) con una notevole quantità di riferimenti e informazioni dettagliate su come impostare le aree di Azure (assicurarsi di posizionare il server SonarQube macchina virtuale nella stessa area TFS) e SQL Server. La creazione di configurazione e del database di SQL Server presenta requisiti specifici per soddisfare per SonarQube. Ad esempio, il Database SQL deve essere tra maiuscole e minuscole e non accentati e non si tratta il valore predefinito. Autenticazione di SQL Server deve inoltre essere abilitata e un utente SQL è configurato per SonarQube per l'utilizzo. Durante l'hosting in Azure è necessario modificare i protocolli di rete per SQL Server abilitare l'accesso al database dall'esterno della macchina virtuale seguendo alcuni passaggi. In primo luogo, utilizzando Gestione configurazione SQL Server, abilitare Named Pipes e TCP / IP per il database SQL Express, come illustrato nella Figura 3.

Attivazione Named pipe e il protocollo TCP/IP per il Database di SQL Express
Figura 3 attivazione Named pipe e il protocollo TCP/IP per il Database di SQL Express

Ancora in Gestione configurazione di Server, modificare le proprietà TCP/IP, nella scheda indirizzi IP, cercare porte dinamiche TCP e prendere nota della porta (49419 qui), come illustrato nella Figura 4. È possibile utilizzarlo per abilitare la connessione al database dall'esterno.

prendere nota del numero di porta nelle porte dinamiche TCP per abilitare la connessione al Database dall'esterno
Figura 4 prendere nota del numero di porta nelle porte dinamiche TCP per abilitare la connessione al Database dall'esterno

Come illustrato nellaFigura 5, riavviare SQL Server facendo clic su SQL Server Express nell'elemento di servizi di SQL Server e scegliere Riavvia. Avviare SQL Server Browser (nella scheda servizio modificarlo da arrestato su automatico e riavviarlo).

Avviare SQL Server Browser
Figura 5 avviare SQL Server Browser

È ora necessario aprire una porta nel firewall in modo che il database è accessibile dal computer di TFS. Al prompt cmd.exe in esecuzione come amministratore, digitare quanto segue:

netsh advfirewall firewall add rule name="SQL" dir=in action=allow
  protocol=TCP localport=49419 49590

SonarQube non richiede l'installazione completa di JVM, dovrebbe essere sufficiente Java SE Runtime Environment (JRE) e sono disponibili consigli specifici su come configurarlo e usufruire di un sistema x64 architettura del processore.

Il programma di installazione della sezione SonarQube Server nella Guida vengono descritte le procedure di download, installazione e configurazione durante la configurazione e avvio SonarQube, incluse le impostazioni di Windows Firewall.

Durante l'hosting in Azure è necessario abilitare l'accesso al server SonarQube per essere accessibile dall'esterno. A tale scopo, innanzitutto disattivare l'accesso anonimo. Per forzare l'autenticazione utente, accedere come amministratore di sistema e passare alle impostazioni | Impostazioni generali | Sicurezza e impostare la proprietà di autenticazione utente Force su true.

Aprire la porta nel firewall per il server Web. È necessario aprire una porta nel firewall in modo che il server Web è accessibile da Internet. Nel prompt di cmd.exe in esecuzione come amministratore, digitare:

netsh advfirewall firewall add rule name="Sonar Web" dir=in action=allow
  protocol=TCP localport=9000

Aggiungere gli endpoint in Azure per Sonar Web e il database. Per il momento, è possibile accedere alla macchina SonarQube con un desktop remoto e accedere al database e il sito Web. È necessario assicurarsi che è possibile connettersi a queste due risorse dal computer su Internet. A tale scopo, è necessario creare gli endpoint in Azure:

  • Vai a indirizzo portal.azure.com.
  • Sfoglia per trovare la macchina virtuale in cui è impostato SonarQube.
  • Nel blade di presentazione di questa macchina virtuale, fare clic su tutte le impostazioni.
  • Nelle impostazioni, fare clic su endpoint.
  • Nel blade endpoint, fare clic su Aggiungi.
  • Aggiungere un endpoint denominato Web Sonar mapping porta pubblica 9000 TCP alla porta privata 9000.
  • Aggiungere un endpoint denominato SQL mapping tra la porta pubblica TCP 1433 e la porta privata 49419 (la porta 1433 è previsto da SQL Server Management Studio o Visual Studio per individuare SQLEXPRESS). Si noti che questo passaggio non sarà più necessario quando viene rilasciato SonarQube 5.2.

SonarQube possibile eseguire analisi in molti linguaggi; è necessario installare il plug-in per le lingue del progetto da analizzare dalla libreria plug-in SonarQube (bit.ly/1NdhnYF) o tramite Centro aggiornamenti SonarQube (bit.ly/1NPKZet). È quindi necessario installare e configurare alcuni prerequisiti dell'agente di compilazione, a seconda del tipo di progetti: MSBuild.SonarQube.Runner (bit.ly/1LOYzM3), una per. Progetti basati su NET-); Plug-in Maven SonarQube runner (per i progetti di linguaggio Maven). e SonarQube Runner, uno sportivo generico per tutti gli altri tipi di progetti.

Integrazione con Team Build e testare la definizione di compilazione modificato, come illustrato nella Figura 6. Lo strumento SonarQube Runner si integra bene con agente di compilazione in modo semplice possono essere effettuata dal team di sviluppo utilizzato per lavorare con TFS.

SonarQube l'analisi con agente di compilazione
Figura 6 SonarQube l'analisi con agente di compilazione

Strategia per gestire un debito tecnico

Ora che l'ambiente SonarQube è impostato, verranno descritti una strategia per poter utilizzare misura debito tecnico all'interno del ciclo virtuoso agile per migliorare il valore per il proprietario del prodotto e l'azienda. Come indicato dal metodo SQALE, la nostra intenzione consiste nel definire chiaramente ciò che crea un debito tecnico, stimare correttamente il debito, analizzare il debito prospettiva tecnico e aziendale e strategie di priorità diversi offerta consentire la creazione di un piano di recupero del capitale investito ottimizzato.

Il metodo SQALE, come illustrato nella Figura 7, viene utilizzato per la formulazione e organizzare i requisiti non funzionali relativi alla qualità del codice. È organizzato in tre livelli gerarchici: caratteristiche, caratteristiche secondari e i requisiti relativi agli attributi interno del codice. (Tali requisiti dipendono in genere contesto e della lingua del software. Qualsiasi violazione di questi requisiti introduce un debito tecnico).

Il metodo SQALE
Figura 7, il metodo SQALE

Il metodo SQALE Normalizza i report derivante dagli strumenti di analisi del codice sorgente da trasformandoli in costi di monitoraggio e aggiornamento e non monitoraggio e aggiornamento. Definisce inoltre le regole per aggregare tali costi, una struttura ad albero del metodo SQALE, seguito o che segue la gerarchia degli elementi del codice sorgente. Per gestire un debito tecnico di un progetto software, è necessario rendere visibile il debito. Assicurarsi che il proprietario del prodotto e marketing personale sapere che un debito tecnico esista e ripetere i loro spesso "Se non si pianifica di tempo per saldare il debito tecnico, potrebbero non essere tutte le funzionalità desiderate."

Si consiglia la metafora di perdita di acqua posticipare il debito tecnico corrente, ad eccezione di ciò che è veramente importante e urgente per correggere, ad esempio, i problemi di sicurezza. Pertanto, richiedere una linea di base, verificare di essere consapevoli del nuovo debito, provare a non introdurre nuovo debito (la perdita di arresto) e come si sta lavorando e refactoring del codice, il tempo di correggere il debito esistente. Si è gli unit test, pertanto non è pericoloso a tale scopo (eseguire la pulizia è).

La gestione di un debito tecnico non deve essere previsto. È una modifica del comportamento nell'intera organizzazione.

Come illustrato nella Figura 8, SonarQube presenta un dashboard basato su SQALE affinché il team per avere una rappresentazione comune dello stato di qualità di un progetto software.

Il Dashboard SonarQube basate su metodo SQALE all'interno di un ciclo di vita del progetto 
Figura 8 SQALE basate su metodo SonarQube Dashboard all'interno di un ciclo di vita del progetto

Figura 9 viene illustrato il widget piramide debito tecnico. Leggere il grafico verticalmente dal basso verso l'alto. In primo luogo, si desidera garantire si sta testabili (40min), in caso contrario, quando si modifica del codice, non è possibile garantire che non vengano più problemi. Quindi si desidera essere affidabile, che avrà un minimo di 42 aggiuntivo; in totale, per essere affidabile occorre dedicare 1 min 22 h e così via.

Il Widget piramide debito tecnico
Figura 9 Widget piramide debito tecnico

Come gestire un debito tecnico?

Di seguito sono i passaggi principali necessari per gestire un debito tecnico:

Passaggio 1: Impostare gli obiettivi del progetto. Deve esistere una definizione di ciò che crea un debito tecnico. Gli indici vengono calcolati in base alle azioni correttive medio stimati dal team di sviluppo. Per visualizzare in modo efficiente i punti di forza e punti deboli del codice sorgente valutato vengono utilizzati diversi grafici e diagrammi. È necessario porsi:

  • Quali parti software contribuiscono al massimo per i rischi?
  • I criteri di qualità sono più interessati?
  • Che cos'è l'impatto dell'identificato non-conformità nel progetto o degli utenti?

Questi sono gli obiettivi definiti su un progetto. SonarQube consente di eseguire il drill down problemi specifici all'interno del codice per capire il motivo e implicazioni e, pertanto, le attività del piano per ripagare il debito. Questa analisi deve essere effettuata durante la pianificazione agile e, se possibile, impostare la priorità lungo gli elementi Backlog prodotto (PBI). I PBI sono definiti e valutati per bilanciare o migliorare la velocità o altre caratteristiche di architettura. Le caratteristiche sono definite da più critico, a quelli che garantirà potenziale valore commerciale, agli utenti come portabilità o riutilizzo di prodotto.

Passaggio 2: Monitorare la quantità di debito tecnico nel tempo. Essere in grado di controllare i risultati delle attività eseguite o procedure consigliate implementate. Domande da porsi includono un debito tecnico aumentato durante l'ultimo giorno dello sprint//Version e quantità margine vi è correlato all'obiettivo impostato per il progetto.

Passaggio 3: Analizzare il processo e l'impatto. È inoltre possibile confrontare un debito tecnico eseguendo le procedure consigliate tra progetti diversi o team o subappaltatori. Ciò può migliorare consigliate tra i team durante le procedure consigliate e li applica in modo più efficace mentre anche migliori risultati debito tecnico di misurazione.

È possibile analizzare l'origine di un debito tecnico rispondendo alle domande, ad esempio quali parte del debito corrente è stato creato durante l'ultimo giorno/sprint/versione, quale parte del debito corrente viene ereditata dal codice legacy e quali parti del progetto sono il debito tecnico più elevato.

Inoltre, team devono concentrarsi su parti specifiche di debito tecnico al fine di ottimizzare i risultati. A tale scopo, porre domande ad esempio in cui sono riportati i problemi più urgenti per correggere il codice, quali sono i problemi da correggere avanti e quali le violazioni di "codice corretto" non sono così i costi di correggere e genererà un'elevata riduzione dell'impatto per l'azienda.

Infine, se spende 100 ore per ridurre il debito tecnico, chiedere quanto migliorerà la velocità? E il miglioramento percepiranno utenti sulla qualità dell'applicazione?

Risposte a queste domande fornirà un meccanismo di feedback naturale per trovare opportunità di miglioramento e chiusura di un prodotto migliore.

Il metodo SQALE supporta tre strategie per l'indirizzamento debito tecnico:

  1. Seguire la logica di documentazione tecnica (evitare inutili variazioni). Utilizzare la piramide SQALE.
  2. Ridurre l'impatto aziendale tramite la correzione non conformità con il massimo impatto aziendale.
  3. Ottimizzare il ROI tramite la correzione non conformità con il ROI più elevato.

Avvolgendo

Debito tecnico deve essere gestito, non necessariamente eliminato e, pertanto, deve essere riconosciuto e misurato. Per interrompere la scelta è un buon inizio. È possibile scegliere di gestirlo verso il basso e sono disponibili diversi modi. Come si tocca il codice per correggere i bug o aggiungere nuove funzionalità, potrebbe essere pulire debito esistente. In alternativa, è possibile decidere correzione azioni sono importanti da eseguire per problemi di sicurezza o di conformità. Probabilmente si tratta della modalità organizzazione pensa deve affrontare il problema. In tal caso, il lavoro deve avere una priorità tra le altre nuove funzionalità o funzionalità desiderata, misurare l'impatto sulle implicazioni.

Si deve imparare a tenere conto delle decisioni che potrebbero aumentare debito tecnico e dovrebbe essere in grado di misurare i miglioramenti scopo effettivamente la gestione.

SonarQube e i componenti di integrazione di TFS consentono di facilitare la raccolta dei dati di compilazione Microsoft Build Engine, oppure in TFS e Visual Studio Online. SonarQube presenta un debito tecnico in modo che consente di comprendere e piano come per una migliore investire per risolverli. È in corso operazioni eseguite da Microsoft e SonarSource (vedere bit.ly/1OeqftX) per migliorare ulteriormente l'integrazione e fornire una soluzione di prima classe per la gestione di un debito tecnico su una piattaforma.


Cesar Solis Britoè stato consulente specializzato nello sviluppo di software nei campi finanziari e farmaceutici e in Microsoft da oltre 20 anni. Attualmente, è un ingegnere di escalation di Microsoft per la piattaforma Azure. Egli ha lavorato attivamente in ALM e tecnologie di sviluppo Microsoft. È possibile contattarlo all'indirizzo Cesar.Solis@microsoft.com o seguirlo su Twitter: @cesarsolis.

Hosam Kamelè senior premier field engineer presso Microsoft e un cane di ALM di Visual Studio con esperienza più di 10 anni di sviluppo del software. Si è attualmente specializzato in Visual Studio ALM e Team Foundation Server. È possibile contattarlo sul suo blog al blogs.msdn.com/HKamel o seguirlo su Twitter: @HosamKamel.

Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Mathew Aniyan, Brian Blackman danno ottimi, Harysh Menon, Duncan Pocklington e Jean Marc Prieur