Gli Azure Web Sites supportano il continuous deployment da strumenti del controllo del codice sorgente e repository com BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial e TFS/VSO. È possibile infatti utilizzare questi strumenti per manutenere i contenuti ed i sorgenti del sito e poi pubblicare le modifiche in modo semplice e veloce.
 |
| Metodi di deploy supportati |
Usando un repository Git locale è possibile, ad esempio, fare la “promozione” manuale degli aggiornamenti da un progetto locale ad un Azure Web Site; deployando invece da strumenti come BitBucket, CodePlex, Dropbox, GitHub, TFS/VSO o Mercurial è possibile abilitare un processo di continuous deployment in cui sarà Azure stesso a fare il pull update più recenti del progetto.
Entrambi i metodi permettono di deployare i progetti su un Azure Web Site, ma il continuous deployment è utile quando ci sono più persone che lavorano su un progetto e ci si vuole assicurare che l’ultima versione sia sempre pubblicata indipendentemente da chi ha fatto l’aggiornamento più recente. Il continuous deployment è anche utile se viene utilizzato uno degli strumenti di cui sopra come repository centrale per l’applicazione.
Su internet ci sono un sacco di articoli che spiegano come fare il deploy di un Azure WebSite (ad esempio http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/) o come implementare delle strategia di Continuous Deployment (es. http://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/).
Ma come funziona in realtà “dietro le quinte”?
La risposta è “Kudu“.
Kudu è il motore che sta dietro il deployments degli Azure Web Sites, ma può anche funzionare al di fuori di Azure.
Ha un’architettura alquanto insolita, nel senso che è un servizio single-tenant anziché multi-tenant. Questo significa che ogni sito Web Azure ha una propria istanza del servizio Kudu, completamente distinta dalle istanze Kudu utilizzate per altri siti Azure.
Il componente rimane attivo in background e “controlla” se si verificano checkin, commit, nuovi file, build e così via. Quando rileva qualcosa, KuduSync inizia e fare il “lavoro sporco”.
Si tratta di uno strumento piuttosto interessante:
- è un progetto open source disponibile su GitHub (https://github.com/projectkudu/kudu)
- è installato automaticamente per ogni Azure Web Sites
- può utilizzare uno script di distribuzione personalizzato
Ma la cosa più importante (imho) è questa:
Il deployment viene creato nella struttura delle cartelle del sito web e il nuova deployment viene copiato nella root del sito, lasciando intatti i vecchi deployment.
Questo significa che è possibile fare il “rollback” a qualsiasi deploy fatto in passato!
È anche possibile accedere alla dashboard web di Kudu, utilizzando un url del tipo “https://your_website_name.scm.azurewebsites.net/” e le deployment credentials associate (oppure le credenziali di un amminisistratore del servizio).
 |
| Dashboard di Kudu |
Nella dashboard di Kudu è possibile trovare un sacco di informazioni utili sull’ambiente del tuo sito web insieme a una serie di strumenti per gestire il sito e, ultimo ma non meno importante, un set completo di API REST. C’è anche la possibilità di gestire le WebSite extension.
C’è anche un interessante video (in inglese) in cui David Ebbo e Scott Guthrie spiegano come funziona Kudu: http://channel9.msdn.com/Shows/Azure-Friday/What-is-Kudu-Azure-Web-Sites-Deployment-with-David-Ebbo
Login