Controllo origine - Web Form di ASP.NET - Squadra inesperta

0

Attualmente sto lavorando in un'azienda che ha un piccolo ( 2 ) team di sviluppo per il nostro progetto WebForms ASP.NET. Questo è stato qualcosa che abbiamo raccolto da una squadra precedente. Il team attuale è composto da neolaureati con poca o nessuna esperienza nel controllo del codice sorgente. Abbiamo tutti letto la pagina gitflow e capisco, semplicemente non capiamo come il processo dovrebbe fluire una volta che un rilascio è pronto e nel ramo principale.

Il team precedente, tuttavia, non ha fornito la fonte, quindi siamo stati lasciati a riscriverlo da zero. Abbiamo introdotto il controllo del codice sorgente nell'azienda e lentamente abbiamo cercato di ripulire il nostro processo di sviluppo. A causa del nostro datore di lavoro, non disponiamo ancora di modelli o standard di sviluppo chiari, ma questa è una discussione per un'altra volta.

Per chiarire, siamo a nostro agio con il controllo del codice sorgente, ma non abbiamo idea di come distribuire in modo pulito e facile da gestire. Non c'è un singolo sviluppatore in questo team che abbia più di 2 anni di sviluppo in un'azienda.

Lavoriamo nelle filiali feature e usiamo le filiali release per spingere, beh, rilasciare, ma la nostra pipeline di distribuzione non esiste. Attualmente trasferiamo il nostro master ramo direttamente sul nostro server di produzione .

Il nostro datore di lavoro preferisce fare gli hotfix (non il tipo GitFlow) a proprio piacimento, senza dire agli sviluppatori . Oggi abbiamo riscontrato una situazione in cui avevamo bisogno di pubblicare una correzione rapida, ma il datore di lavoro aveva apportato alcune modifiche in tal senso, quindi abbiamo dovuto dedicare un'ora a lavorare su quelle. Se vogliamo applicare un hotfix sul server di produzione, dobbiamo prima controllare il nostro ramo di sviluppo, il che significa anche interrompere i nostri clienti più di quanto vorremmo.

La domanda che ho è questa, come dovremmo gestire il nostro controllo del codice sorgente? Dovremmo davvero spostare il ramo principale direttamente sul nostro server di produzione?

Siamo tutti inesperti nel controllo del codice sorgente, non usandolo mai per fornire un prodotto prima. Attualmente sono lo sviluppatore principale e sto cercando di ottenere un certo ordine prima che portiamo altri sviluppatori. Qualsiasi consiglio è benvenuto.

    
posta Mykrosoft 14.08.2017 - 18:02
fonte

1 risposta

0

Sono in una situazione molto simile con una squadra leggermente più grande. Una delle principali differenze è che ogni membro ha set di competenze e esperienze uniche quando si tratta di sviluppo. Il problema più difficile che ho riscontrato è quello di convincere non solo la società a rispettare il nuovo flusso di sviluppo, ma a far sì che ciascuno dei membri si attenga ai processi concordati. Tieni presente che, anche se il datore di lavoro non ritiene che ciò sia importante, fai del tuo meglio per seguire il flusso che viene stabilito. Sei in una posizione perfetta per impostare un flusso prima che la tua squadra diventi grande e indisciplinata.

L'altro problema che ho riscontrato di recente è che c'è una grande differenza tra un'applicazione di moduli web e un sito web di moduli web.

link

Quando si tratta di controllo del codice sorgente, ognuno può essere gestito in modo molto diverso. Con un'applicazione web, il codice sorgente dovrebbe essere messo in git e compilato per essere eseguito. Con un sito Web, tutto nella directory viene compilato automaticamente ed è già in uno stato che può essere utilizzato sia per lo sviluppo che per la produzione. Ciò rende troppo semplice apportare modifiche alla produzione e interrompere il flusso.

Per quanto riguarda i rilasci e il flusso di sviluppo, utilizziamo un approccio a più fasi che coinvolge il metodo blu / verde.

  1. Ambiente di sviluppo - Macchina dedicata per lo sviluppo / Copie locali
  2. Ambiente di test - Server / sito dedicato
  3. Ambiente di produzione (blu) - Server / sito dedicato
  4. Ambiente di produzione (verde) - Server / sito dedicato

Lo sviluppo normale o lo sviluppo delle diramazioni viene eseguito sull'ambiente Dev. L'ambiente Dev può essere eseguito su una macchina di sviluppo locale o può esserci un sistema dedicato alla sua esecuzione. Una volta soddisfatti delle modifiche al codice, spostiamo il ramo nell'ambiente di test. È qui che eseguiamo l'usabilità e il testing delle funzionalità. Questo ambiente è collegato al database fittizio con dati falsi. Una volta che siamo soddisfatti del test, uniamo le modifiche nel master e trasferiamo il rilascio su Blue. Facciamo poi qualche piccolo test solo per assicurarci che i dati in tempo reale mostrino i risultati corretti. Una volta ottenuta l'approvazione del capo squadra, giriamo il blu al verde.

Ciò significa che la directory del sito per l'ambiente di produzione blu diventa l'istanza live, mentre la versione verde rimane disponibile ma offline. Questo è bello avere se qualcosa fallisce che non è stato risolto durante i test e un rollback è necessario.

Tutto questo può essere fatto nei virtual e anche sullo stesso server IIS se necessario. All'inizio potrebbe sembrare un po 'intimidatorio, ma fornisce una grande quantità di ridondanza e protezione durante lo sviluppo di un sito Web ASP.net Webforms.

    
risposta data 15.08.2017 - 00:54
fonte

Leggi altre domande sui tag