Tag Archives: VSALM
Mettere il Database sotto Source Control – eBook gratuito
Normalmente, un sistema di Source e Version control mostra enormi benefici nel coordinamento del lavoro dei team di sviluppo, garantendo un audit trail completo di tutte le modifiche ai file di codice e permettendo alla squadra di tenere traccia di qualsiasi versione specifica o build.
Anche gli sviluppatori di database possono (e dovrebbero…) trarre beneficio dal audit history e dalle funzionalità di change-tracking, c’è molto di più che salvare qualche script DB in una sottocartella dell’applicazione sul sistema di source control. A differenza di chi sviluppa applicazioni, i database developers non assemblano file e classi in un pacchetto applicativo, ma invece eseguono script che magari si alimentano a vicenda o da altri oggetti esistenti instaurando una stretta interdipendenza tra il codice ed i dati.
Per coprire quello che possiamo chiamare “Database Lifecycle Management“, e considerare un ramo dell’ALM, RedGate ha sviluppato un interessante ebook gratuito, dal nome “SQL Server Source Control Basics“.
Purtroppo, gli autori del libro hanno deciso di utilizzare SVN, ma i concetti chiave si possono applicare senza problami anche a Team Foundation Server o Visual Studio Online.
Tra gli argomenti trattati ci sono:
Concetti fondamentali dei sistemi di source control
Scegliere un sistema di version control per il database e definirne la struttura
Strategie di branch e merge
Automatizzare il versionamento del database ed il suo deployment
Introduzione al “Database continuous integration”
L’eBook offre una guida dettagliata sui concetti di Database source control con esempi chiari e completi.
Può essere scaricatoto, gratis, qui (disponibile solo in lingua inglese):
Visual Studio Online REST API versione 1.0
Oggi è stata rilasciata la prima versione ufficiale delle REST API di Visual Studio Online, la 1.0.
Annunciate in preview in maggio, ora hanno raggiunto una maturità tale da spingere il team di sviluppo a chiudere la prima release. Questo non significa che non ci saranno cambiamenti o che gli sviluppi siano terminati; significa che le funzionalità core sono ora complete e da qui in avanti verranno versionate per mantenere la compatibilità all’indietro, in modo che tutte le applicazioni ed i servizi che le utilizzano rimangano comunque funzionanti a prescindere dagli aggiornamenti futuri.
Congiuntamente all’annuncio, il team ha modificato il “API Reference portal” e la “Getting started guide“
Importante
Se avete delle applicazioni esistenti che utilizzano la versione 1.0 preview delle API, dovreste iniziare la migrazione alla release 1.0 prima possibile; infatti la versione 1.0 preview (e precedenti) smetteranno di funzionare in 12 settimane da oggi. Per sapere di più sul versioning e sulla migrazione è possibile consultare la “versioning and migration page“.
Detto questo, ricordate che a partire da oggi, quindi, le Visual Studio Online REST API seguono questo pattern:
VERB https://{account}.VisualStudio.com/DefaultCollection/_apis[/{area}]/{resource}?api-version=1.0
Integrare un’applicazione o un servizio con Visual Studio Online – Guest Post MSDN
Venerdì scorso è stato pubblicato su MSDN Italia il mio secondo Guest post, in cui parlo di com’è possibile e facile integrare le nostre applicazioni e servizi con Visual Studio Online utilizzando le nuove REST API ed i Service Hooks.
Per leggere l’articolo completo utilizzare il link sottostante:
Migrare facilmente da Team Foundation Server a Visual Studio Online – Guest Post MSDN
Oggi è stato pubblicato su MSDN Italia un mio Guest post in cui spiego come effettuare la migrazione da un Team Foundation Server (quindi normale scenario di installazione on-premises) al suo corrispettivo on-cloud Visual Studio Online e quali sono le motivazioni che potrebbero spingerci a farlo.
Per leggere il post utilizzare il link sottostante:
Creare un Work Item con le REST API – Visual Studio Online
A volte può essere utile aggiungere un nuovo Work Item ad un nostro Team Project in modo automatico, magari in risposta ad un determinato evento.
Le nuove “WIT REST API v1.0 (preview 2)” (rilasciate il 4 settembre) esposte da Visual Studio Online ci permettono di farlo.
Quando creiamo un work item, possiamo indicare i valori per qualsiasi tipo di work item fields.
Per creare un work item, è necessario effettuare una richiesta HTTP PATCH a:
https://your_account.visualstudio.com/defaultcollection/team_project_name/_apis/wit/workitems/$work_item_type_name?api-version=1.0-preview.2
Il body della richiesta deve essere valorizzato in base a questo formato:
[
{
"op": "add",
"path": { string }
"value": { string or int, depending on the field }
},
{
"op": "add",
"path": "/relations/-",
"value":
{
"rel": { string },
"url": { string },
"attributes":
{
{ name/value pairs }
}
}
}
]
Un esempio di richiesta potrebbe essere:
https://myAccount.visualstudio.com/defaultcollection/myProject/_apis/wit/workitems/$task?api-version=1.0-preview.2
[
{
"op": "add",
"path": "/fields/System.Title",
"value": "Change blog title height"
}
]
Questa richiesta produce una response come la seguente, in cui si possono trovare tutte le informazioni relative al work item appena creato:
{
"id": 88,
"rev": 1,
"fields": {
"System.AreaPath": "myProject",
"System.TeamProject": "myProject",
"System.IterationPath": "myProject",
"System.WorkItemType": "Task",
"System.State": "To Do",
"System.Reason": "New task",
"System.CreatedDate": "2014-09-30T10:25:12.943Z",
"System.CreatedBy": "Davide Benvegnu",
"System.ChangedDate": "2014-09-30T10:25:12.943Z",
"System.ChangedBy": "Davide Benvegnu,
"System.Title": "Change blog title height"
},
"_links": {
"self": {
"href": "https://myAccount.visualstudio.com/DefaultCollection/_apis/wit/workItems/88"
},
"workItemUpdates": {
"href": "https://myAccount.visualstudio.com/DefaultCollection/_apis/wit/workItems/88/updates"
},
"workItemRevisions": {
"href": "https://myAccount.visualstudio.com/DefaultCollection/_apis/wit/workItems/88/revisions"
},
"workItemHistory": {
"href": "https://myAccount.visualstudio.com/DefaultCollection/_apis/wit/workItems/88/history"
},
"html": {
"href": "https://myAccount.visualstudio.com/web/wi.aspx?pcguid=0fa87894-6f48-4458-957d-3438b6bb9343&id=88"
},
"workItemType": {
"href": "https://myAccount.visualstudio.com/DefaultCollection/c4637008-2068-4b3f-828d-a214e2ba5210/_apis/wit/workItemTypes/Task"
},
"fields": {
"href": "https://myAccount.visualstudio.com/DefaultCollection/_apis/wit/fields"
}
},
"url": "https://myAccount.visualstudio.com/DefaultCollection/_apis/wit/workItems/88"
}
Azure Web Sites Deploy: come funziona?
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
Visual Studio Online ora supporta Azure Active Directory
Ieri il team vsalm di Microsoft ha iniziato il deploy dello sprint 68.
La parte più grande ed interessante dell’annuncio è la nuova fase del supporto di Azure Active Directory in VS Online. Hanno iniziato questo “viaggio” in maggio quando hanno annunciato le prime parti del supporto all’AAD a “Build”. Poi hanno aggiunto alcune (poche) altre informazioni durante “TechEd” ma era una cosa passata un po’ in sordina visto che, fino a questa settimana, non era possibile convertire o associare un account esistente ad AAD. Con questo deploy, invece, diventa possibile! Ufficialmente è in preview e quindi è necessario richiedere l’accesso alla funzionalità, ma sembra accettino tutte le richieste quindi non dovrebbe essere un grosso problema (anche perchè va fatto una volta sola).
Con queste modifiche, è possibile:
- Associare un OrgID (ovvero credenziali AAD/AD) alla sottoscrizione MSDN, se ce n’è una, ed usarla come grant per la licenza VSO
- Creare un nuovo account collecato ad AAD
- Collegare un account esistente ad AAD
- Scollegare un account da AAD
- Accedere sia con un Microsoft Account che con un OrgID (solo AAD oppure in sycn con l’Active Directory on premises) creando di fatto un SSO con le credenziali corporate, Office 365, ecc.
Per vedere tutti i dettagli riguardo il supporto AD e le altre cose incluse nell’update è possibile leggere il post originale di Brian Harry su MSDN.
Login