Le Post Infeeny

Les articles des consultants et experts Infeeny

Microsoft Ignite 2015 – Dealing With Application Lifecycle Management in Office 365 App Development – Jeudi 7 mai

Par Stéphane,
Pôle SharePoint MCNEXT

Dealing With Application Lifecycle Management in Office 365 App Development
Code : BRK4126

Niveau : 400
Cible : Développeurs
Présentateur : Chris O’Brien

Travail sur le processus de développements d’apps SharePoint ou Office 365. Approche pragmatique et beaucoup de bonnes idées, à voir à tout prix !

Généralités

Application Lifecycle Management (ALM) :
– Efficacité dans le développement grâce à des processus
– Planification des mises à jour et minimisation du stress
– Déploiements sans surprise

Techniques :
– Intégration continue
– Déploiement continue
– Vérification de la qualité du code
– Processus de déploiement structurés

Avant :
Environnement TFS On-premise
Environnement SharePoint On-Premise
Personnalisation des builds
Beaucoup de scripts

Bonne nouvelle ! Tout cela est plus facile avec les apps

Apps :
– Application Office 365
– Add-ins pour SharePoint et Office
Ces deux sont des applications asp.net

Hébergement :
– Azure
– Autre Cloud
– Environnements On-premise

Azure vaut le coup d’être considéré pendant le développement :
– Check-in développeur
– La build s’exécute
– Le résultat est automatiquement déployé sur Azure Web App.
Azure facilite énormément ce processus.

Application aux apps O365

1 – Il crée une app Office 365 sur Visual Studio à partir d’un modèle.
2 – Il enregistre l’application sur O365, note l’URL et enregistre les permissions. L’application est bien enregistrée par Visual Studio dans les applications de Azure AD. Tout est très fluide.
3 – Il configure l’application en mettant l’ID du tenant dans la solution Visual Studio
4 – Il enregistre la solution dans Visual Studio Online. Cela simplifie le processus.
5 – Il crée un site web sur Azure pour héberger l’app
6 – Il crée un lien entre le site et visual studio online en sélectionnant « Publish from source control »
7 – Visual Studio publie l’app par le système de builds
8 – L’application fonctionne et les changements sont poussés à chaque check-in.

Gestion des environnements dev/test/production

– Utiliser plusieurs tenants ? Attention, plusieurs considérations. Notamment le fait que les environnements Azure sont séparés. Tout devient compliqué parce qu’il faut faire plusieurs enregistrements, les environnements ne sont pas bien configurés et toutes les fonctionnalités ne sont pas disponibles en développement.
– Utiliser les deployment slots d’Azure. Chaque site a une URL différente. On peut ensuite échanger les environnements.

Démonstration :

1 – Il crée un slot « staging »
2 – Il modifie sa build pour utiliser ce slot
3 – Il enregistre l’app à nouveau pour le slot « staging »
4 – L’app de staging est déployée au Office 365 de production. Une erreur apparaît car le web.config de l’app ne correspond pas au slot. Pour cela il utilise la possibilité pour Azure de surcharger le web.config au niveau du slot dans la section app Settings
5 – L’app staging fonctionne maintenant convenablement
6 – Il met à jour l’app staging
7 – Il utilise l’option « swap » d’Azure pour passer le staging en production
Le swap permet de donner une option de rollback : il n’y a plus qu’à en refaire un. Mais, il nous faut maintenant mettre à jour la branche de développement car elle a l’ancienne version de production. Faire cela lorsqu’il n’y aura plus de besoins en rollback.

Dans SharePoint

– Il est facile de tester et déployer sur Office 365
– L’intégration continue fonctionne aussi sur Office 365

Démonstration :
1 – Il modifie les options de build pour indiquer de déployer le paquet d’app en plus
2 – Cela fonctionne

Alternatives aux méthodes présentées

– Si on ne peut pas utiliser Visual Studio Online ? La source peut être changée pour le site Azure. On peut utiliser git ou dropbox ou un repository externe
– Si on doit utiliser un TFS On-prem ? Utiliser des scripts de http://officesharepointci.codeplex.col pour des scripts permettant d’assister dans le processus de création de la build
Qualité du code

– Unit tests
– Record Codes UI Tests (difficile)
– Vérification automatique SPCAF qui fonctionne bien avec les apps

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :