Come fanno le aziende SaaS verificare e monitorare il codice rilasciano ai clienti?

Question

Sto lavorando presso una società SaaS che rilascia nuove funzionalità e correzioni di bug per i nostri clienti ogni sei settimane. Quando si scrive modifiche di codice che passano attraverso passaggi differenti (come una macchina a stati) prima di raggiungere il server di produzione. I passaggi sono diversi a seconda se il cambiamento avviene nel ciclo di sviluppo normale o come una correzione di emergenza. Al momento stiamo utilizzando Harvest per gestire le operazioni e tenere traccia di quale codice (caratteristiche e correzioni di bug attraverso pacchetti) è di essere rilasciato ai clienti e in questo senso si sta lavorando bene.

Purtroppo Harvest è sia costoso e un dolore per l'utilizzo dal punto di vista di un programmatore. Ramificazione e la fusione è un incubo. Quindi stiamo esaminando il passaggio a Mercurial. Mercurial sembra eccellere in quelle zone. Tuttavia, Mercurial non sembra essere fatto per il rilevamento delle modifiche o gestire il processo di cui sopra menzionati, lo fa solo SCM.

D: Quali opzioni abbiamo quando si tratta del processo di rilascio, sicuramente ci sono altre aziende SaaS (ad esempio Google, Flickr, Facebook, LinkedIn) là fuori che vuole il controllo di qualità prima di rilasciare il codice per server di produzione?

D: E 'una cattiva idea per cercare di costruire il processo in Mercurial o ci sono altri strumenti che abbiamo bisogno di usare insieme a Mercurial

[Edit] Per chiarire, questo è il nostro (consigliato) struttura ramo .

Ecco il flusso di processo attualmente abbiamo in Harvest:

Hotfix <--> Test Level 1 <--> Test Level 2 <--> Master (Production)
Feature <--> Test <--> Release Test <--> Master (Production)

Io non sto cercando un bug tracker, ma piuttosto uno strumento di distribuzione che ci aiuta a tenere traccia e il codice distribuirlo è stata verificata dai nostri tester (codice nel ramo di release). Se v'è più di un aggiornamento rapido in lavorazione, allo stesso tempo abbiamo bisogno di essere in grado di testare insieme e se si rompe il codice abbiamo bisogno di essere in grado di "demote" il codice di rottura cambia indietro di un passaggio nel flusso di processo. Oggi è sufficiente per i due sviluppatori di "promuovere" i loro cambiamenti al Test di livello 1 e il sistema può essere testato con entrambe le modifiche insieme. Se uno sviluppatore modifiche rompe qualsiasi cosa solo quando è insieme con il codice dell'altro sviluppatore può facilmente essere di nuovo abbassato di livello dal Test di livello 1.

Answer 1

Sono venuto a rendersi conto che quello che stiamo cercando non è un issue tracker, ma piuttosto uno strumento di distribuzione per sostituire questo aspetto del Raccolto. Go e Anthill Pro sono due candidati.

Answer 2

  

Tuttavia, Mercurial non sembra essere fatto per il rilevamento delle modifiche o gestire il processo di cui sopra menzionati, lo fa solo SCM.

E 'meglio utilizzare uno strumento separato per la gestione dei problemi. In questo modo è possibile utilizzare il best of breed per ogni attività. Basta fa in modo che si seleziona uno che si integra bene con il sistema di controllo versione.

Per dare alcuni esempi: jira (commerciale) e trac (gratuito) entrambi hanno i plugin di integrazione mercuriali. Essi hanno anche gli stati del flusso di lavoro personalizzabile, che consente di modellare il processo.