Domande sullo sviluppo per l'azzurro

3

Al momento disponiamo di un'app Web MVC .Net con un database back-end del server SQL e due servizi Web che eseguono periodicamente alcune attività di elaborazione nel database.

Sto pensando di confezionare questa app per il cloud, in cui un client la "istanzia" come un intero pacchetto. Questo processo allocare automaticamente i pezzi necessari per eseguire l'intera cosa, vale a dire il sito, il database e gli altri due servizi.

Ho letto parecchio sull'azzurro e sto attraversando un periodo molto difficile per capire l'intero processo di sviluppo, test e implementazione, quindi aggiornare e applicare le modifiche alle distribuzioni esistenti. Sono abituato ad avere il controllo di tutti i pezzi. Per prima cosa mi piace avere tutto in locale sulla mia workstation. Usiamo git e abbiamo il nostro repository autogestito. Trovo strano avere un ambiente di sviluppo su un computer cloud remoto. Penso che il codice sorgente sia una delle risorse più preziose di un'azienda insieme ai dati (i dati in più).

Nell'attuale ambiente costruiamo le app manualmente (so che è lungi dall'essere ideale, automatizzeremo questo processo e per ora non sono preoccupato) e lo implementeremo semplicemente copiando la nuova versione di top of the old uno. Facciamo anche backup, ricompiliamo le stored procedure di database e applichiamo script che massaggiano i dati, cambiano le strutture delle tabelle o aggiungono indici e così via. Ci sono alcuni tempi di fermo assegnati mentre gli aggiornamenti sono fatti. Prima di implementare in produzione, vengono implementati negli ambienti di integrazione e test.

In che modo tutto questo si traduce in un'architettura azzurra?

Ecco il mio modello mentale:

  • Lo sviluppo e l'integrazione sono fatti a livello locale.
  • Il software è confezionato localmente come SAAS e caricato nel cloud. Presumo che il cloud avrà un manifest che include tutte le risorse di cui l'app ha bisogno e le assegnerà quando l'app viene creata la prima volta nel cloud. Questo processo dovrà essere testato nel cloud da noi.
  • Come per gli aggiornamenti, gli aggiornamenti dovrebbero essere applicati dal client alle distribuzioni esistenti. Immagino che un'altra opzione sarebbe quella di creare una nuova istanza e migrare i dati da quello vecchio. Vedo gli aggiornamenti come pacchetti che possono essere rilasciati sulle distribuzioni esistenti e svolgeranno determinate attività, proprio come un software di installazione che esegue un aggiornamento su una versione precedente. Gli aggiornamenti sarebbero stati testati anche nel cloud.

Suppongo che l'app possa avere tempi di inattività minori. Mi rendo conto che altre app potrebbero non avere questo lusso, ma non voglio andare lì ora.

Ad ogni modo, è fattibile nel mondo azzurro? Qualcosa dovrebbe essere fatto in modo diverso? E come si carica in questo modello?

Grazie

Un aggiornamento: stavo riflettendo su di esso e immagino che un altro modello sarebbe stato costruire un'app monolitica che avrebbe permesso agli utenti di registrarsi per il servizio (proprio come un'app di posta elettronica) e allocare le risorse di conseguenza. Suppongo che in questo caso il modello di ricarica sia più semplice. Il rovescio della medaglia è che l'app dovrebbe essere progettata per essere multi-tenant e avrebbe una serie di sfide. Sono ancora confuso su come l'intero ciclo di sviluppo di test- > funzionerebbe in questo caso.

    
posta costa 22.01.2016 - 08:57
fonte

1 risposta

2

Parte del problema con Azure è che ci sono spesso diversi modi per ottenere lo stesso risultato: nel caso di un sito web le opzioni vanno da App Services a Virtual Machines.

La tua soluzione è probabilmente la migliore implementata come servizio app, in pratica quello che una volta era chiamato un sito Web di Azure e ciò che suona come due lavori Web insieme a un database SQL.

Per mantenere il modello semplice (ovvero coerente con il tuo attuale utilizzo) puoi avere quanti di questi vuoi (entro limiti ragionevoli) e c'è spazio per il ridimensionamento all'interno dei servizi di app di Azure e dei server SQL (pool di database elastici).

Esistono diversi modelli di implementazione, dettagliati qui: Distribuisci la tua app al servizio app di Azure e allo stesso modo è possibile connettersi alle istanze del server SQL di Azure allo stesso modo di qualsiasi altro per eseguire la manipolazione necessaria. Quindi in pratica puoi fare la stessa cosa che fai ora, ovvero copiare i file usando FTP o qualcosa di un po 'più creativo sulla stessa linea (OneDrive / Dropbox). Probabilmente finirai con la distribuzione sul Web. Devi assolutamente non usare git deploy (in realtà probabilmente non vuoi ...)

Non ho giocato abbastanza per essere fiducioso, ma puoi raggruppare risorse azzurre: immagino che ciò possa essere fatto su un cliente e per le istanze di test e qa.

Se fossi in me ... penserei al processo di build / deploy - automatizzare, iniziare a usare un build server, fare in modo che il build server generi pacchetti per la distribuzione, promuovere quei pacchetti attraverso test e integrazione e poi distribuire come si adatta alle istanze del cliente. Allo stesso modo, guarda ad automatizzare le modifiche dello schema - fondamentalmente questo significa automatizzare l'esecuzione degli script e assicurarti di eseguirli nella giusta sequenza e una volta sola (questo è fondamentalmente un problema risolto, ci sono strumenti ...)

In tutta questa automazione sei amico - automazione == ripetibilità e (soprattutto) toglie lo stress. Strumenti come AppVeyor (un build server) e Octopus deploy (uno strumento di distribuzione) comprendono Azure e ti aiuteranno.

    
risposta data 22.01.2016 - 14:18
fonte

Leggi altre domande sui tag