Funzionalità alterna e caratteristica Rami

Question

Che cosa sono i "selettori di funzionalità" e "Rami di caratteristiche" e qual è la differenza tra loro?

Quali sono i pro e i contro? Perché uno è migliore dell'altro?

Ho trovato alcuni articoli su Google relativi a questo, e io tendo ad essere nel campo "Feature Toggles", ma non sono convinto che "Toggles Feature" sia la scelta migliore in tutti i casi.

Answer 1

I selettori di funzioni sono metodologia utilizzata in una catena di integrazione/consegna continua (CI/CD) (metodologia di progetto Agile/Kanban). Fondamentalmente, si inviano nuove funzionalità alla produzione in uno stato disabilitato, quindi in una console di amministrazione attivare la funzionalità (o disattivare se si scopre che è rotto).

I rami di funzione possono essere parte di una metodologia di rilascio e integrati in una catena di integrazione continua. È possibile sviluppare in un ramo di funzionalità, distribuire il ramo su DEV/QA, ottenere la certificazione, unire il ramo di funzione a trunk, quindi spingere il trunk in ambienti SIT/UAT/PROD.

Ci sono pro e contro associati a questo approccio. La funzionalità di commutazione richiede una disciplina molto rigorosa in quanto il codice spezzato/scuro lo sta rendendo in produzione. Questo è ottimo per le start-up e i negozi dove la gestione sa come farlo e ha strumenti di automazione del sistema in atto (Chef/Puppet/cfengine, ecc.) Google, Facebook, LinkedIn, WordPress si distribuiscono negli ambienti di produzione tramite l'attivazione e l'automazione del sistema .

Esistono alcuni "tecnici" prerequisiti per il corretto funzionamento delle funzioni: Consegna/Distribuzione continua, Integrazione continua, Test unità automatizzato, Test di integrazione automatizzata, Test automatico di stress/prestazioni, Automazione del sistema. Se non si dispone di questi in luogo, prendere in considerazione una strategia di rilascio più semplice (ad esempio funzionalità di ramificazione.)

Answer 2

Caratteristica commutazione richiede una disciplina molto severa come codice rotto/scuro è rendendolo alla produzione.

Sono d'accordo Electrawn, ho utilizzato la funzionalità di ramificazione lungo 6 anni, perché nel nostro caso, non abbiamo i requisiti preliminari.

È anche importante capire che la "Strategia di Toogle" trasferisce lo sforzo trascorso in Strategia di Branche delle funzionalità (Unione) in un altro momento.

http://martinfowler.com/bliki/FeatureToggle.html

E 'molto importante per andare in pensione i comandi una volta che le caratteristiche in sospeso sono letti dalla produzione. Ciò comporta la rimozione delle definizioni sul file di configurazione e su tutto il codice che le utilizza. Altrimenti avrai una pila di levette che nessuno ricorda come usare. In un esempio memorabile di cui ho sentito parlare, , era necessario effettuare una ricompilazione speciale del kernel di Linux per gestire abbastanza opzioni da riga di comando.

Nota: seguendo i principi SCM se qualcuno apre e modifica un file potrebbe essere un codice non funzionante.

Quindi, nella mia prospettiva non credo in una "scelta migliore in tutti i casi", perché dipende dalla cultura della tua squadra e se hai la copertura del test.

Beh, è ​​una domanda molto polemica.

Nel mio caso preferisco ancora la strategia Branches delle caratteristiche. Mantenendo le best practice SCM e pianificando la roadmap, il processo di unione tende ad essere un modo semplice. Durante questi anni, ho sentito un sacco di gente si lamenta processo di unione, ma in gran parte dei casi il problema della fusione è la stessa nella mia esperienza, "la comunicazione non" :)

Scusate risposta impreciso, ma penso ci sono alcuni aspetti umani intorno a questo argomento di scelta migliore in SCM.

Answer 3

ho discuterne in modo approfondito sul mio blog: http://geekswithblogs.net/Optikal/archive/2013/02/10/152069.aspx

In breve, questi rami vi darà un migliore isolamento, ma richiedono di affrontare il dolore di integrazione posticipata, e si fonde. I commutatori forniscono un'integrazione continua, ma richiedono di progettare/implementare il codice in modo tale da supportare i commutatori e introdurre il rischio che il codice di funzionalità incompleto possa influire negativamente sulla produzione.

È possibile utilizzare entrambi i rami e i commutatori (non si escludono a vicenda). Per quanto riguarda decidere quale usare in ogni scenario, i miei pensieri sono che alterna dovrebbe essere la scelta di default a meno che il seguente requisito:

• difficile nascondere le funzionalità dietro una ginocchiera
• ha un potenziale impatto sulla un'area dell'applicazione che non ha test approfonditi

Se una di queste condizioni è vera, probabilmente utilizzerei un ramo di funzionalità invece di commutare.