Mettre en place du déploiement continue en local depuis VSTS

Objectif

L’objectif de cet article est de vous présenter comment mettre en place une chaine de déploiement continue sur un serveur IIS local, hébergé sur votre réseau, à partir de code source stocké dans Visual Studio Team System.

Contexte

Vous stockez  sur VSTS les code sources de vos différents projets applicatifs, mais vous aimeriez mettre en place un chaine de déploiement continue sur vos propres serveurs OnPremise n’ayant pas accès à internet à partir du code source contenu dans votre environnement VSTS.

La solution est de passer par un serveur build intermédiaire qui effectuera aussi le déploiement en local. Ce dernier  aura donc un accès à VSTS et au serveur cible IIS hébergé dans le réseau interne.

VSTS_BuildInterne

Serveur de Build

Nous avons utilisé dans notre cas un serveur de Build avec Windows Server 2012 R2. Mais il est possible d’utiliser le poste de développement en guise de serveur de Build, à condition de respecter les prérequis suivant :

 

L’environnement de développement doit être installé sur le serveur de build et l’agent de build, afin que celui-ci puisse effectuer la compilation du code source contenu dans le VSTS.

Installation et Configuration

Environnement de développement

Il est préférable d’installer et de configurer l’environnement de développement avant de configurer l’agent de build, car ce dernier détecte automatiquement l’environnement du serveur lorsqu’il se connecte à VSTS.

Dans notre cas nous avons installé :

  • Visual Studio 2015 Enterprise, version minimum recommandée
  • NodeJs pour la compilation des less avec gulp
  • Framework 4.6.2

Agent de build

Prérequis de sécurité

Pour installer et configurer l’agent de build, utiliser un compte qui soit à la fois Administrateur du Serveur de build et qui soit administrateur dans VSTS.

Authentification avec un « Personal Access Tokens »
  • Connectez vous sur votre VSTS avec le compte administrateur que vous souhaitez utiliser
  • Ouvrez le profil du compte
  • Allez dans sécurité

PAT_1

  • Allez dans Personal Acces Tokens
  • Cliquez sur PAT_2
  • Cochez seulement le scope Agent Pools (Read, manage), et veillez à laisser les autres décoché

PAT_3.png

  • Cliquez ensuite sur PAT_4

PAT_5

  • Copiez le token ainsi obtenu

Note : Veillez à conserver précieusement le token généré, il sera utile pour configurer et supprimer l’agent.

Installation

Pour installer l’agent sur le serveur de build :

  • Connectez vous sur le serveur de build, avec un compte administrateur
  • Depuis le serveur, connectez vous sur votre VSTS avec un compte administrateur.
  • Allez dans Settings\Agent Pools
  • Cliquez sur  DownLoadAgnet

Une fenêtre contenant les commandes à effectuer pour installer sur différent OS s’ouvre.

DownLoadAgent_2

Lancer le téléchargement à la fin de celui-ci exécuter les commandes PowerShell du bloc Create Agent. Ceci décompressera le zip précédemment téléchargé dans le répertoire C:\agent.

Configuration

Création du pool

Lors de la configuration de l’agent de build, nous allons le rattacher à un pool que nous avons spécialement créé :

  • Connectez vous sur votre VSTS avec un compte administrateur.
  • Allez dans Settings\Agent Pools
  • Cliquez sur « New Pool… » New_Pool
  • Dans la fenêtre de saisie, entrez le nom du nouveau pool : « Interne »

Create_Pool

Agent de build

Nous pouvons passer, maintenant, à la configuration de l’agent de build :

  • Dans la console PowerShell  en tant qu’administrateur, placez vous dans le répertoire où a été installé l’agent
  • Exécuter la commande :Configuration_agent_1

Un assistant de configuration en ligne de commande PowerShell démarre :

Connexion à VSTS :

Configuration_agent_Connection_PS_3
  • Saisissez l’URL VSTS : https://{your-account}.visualstudio.com
  • Sélectionnez le type authentification PAT (précédemment configuré avec le compte que vous utilisé)
  • Saisissez le jeton précédemment généré

Inscription de l’agent sur VSTS :

Configuration_agent_Inscription_PS_4

 

  • Saisissez le nom du pool d’agent précédent créé : Interne
  • Saisissez le nom de l’agent, par défaut il vous propose le nom du serveur : BuildInterne
  • Saisissez le dossier de travail de l’agent : _workVSTS
  • Choisissez de l’exécuter en tant que Service, en saisissant ‘O’
  • Choisissez le compte par défaut

Résultat :

  • Connectez vous sur votre VSTS
  • Allez dans Settings\Agent Queues

Vous  devez voir le résultat suivant :

Configuration_agent_Resultat_VSTS

Vous pouvez utiliser maintenant le pool Interne dans la configuration de vos Builds.

Note : Sur un serveur de build, vous pouvez installer plusieurs agent de build, il faut juste les utiliser des répertoires d’installation différents.

Création d’un Build VSTS

  • Connectez sur VSTS
  • Allez dans « Build & Realease »/Builds

 

Create_Build_1.png

  • Cliquez sur New

Create_Build_2

  • Sélectionnez le Template ASP.NET et cliquez sur « Apply »

Create_Build_3

  • Allez dans l’onglet « Triggers » pour activer l’intégration continue
  • Préciser la branche à surveiller

 

Create_Build_4.png

  • Allez dans l’onglet « Options » pour sélectionner l’agent interne précédemment créé

Create_Build_5.png

  • Allez dans l’onglet « Variables » Afin de modifier :
    • BuildConfiguration selon la configuration souhaitez (Release, Debug, ou une que vous avez créée dans votre solution). Dans notre cas, nous avons créé la configuration de Build « Developpement »

Create_Build_Variables

  • Cliquez sur « Save »

Save_Build_6.png

  • Cliquez sur « Save »

 

Déploiement automatique

L’objectif est déployer automatiquement sur le serveur cible IIS, le dernier package compilé par le pool de build que nous venons de créer avec l’agent « BuildInterne ».

Configuration du serveur Cible

Dans notre cas nous effectuons le déploiement automatique sur un serveur web IIS Windows server 2012 R2.

Sur ce dernier, il faut activer WinRM : Remote Management.

WinRM

Pour activer WinRM sur Windows Server 2012 :

  • Connectez vous sur le serveur Cible
  • Ouvrir sur le serveur Server Manager > Local Server

Server_manager

Site Web Cible

Dans notre exemple, nous allons mettre en place un déploiement automatique sur un site web existant que nous allons créer sur le serveur manuellement. mais cette action est parfaitement automatisable dans le processus de déploiement automatique.

  • Connectez vous sur le serveur cible
  • Ouvrir sur le serveur IIS manager
  • Ajouter un nouveau site Web, par exemple : WebInterne sur un port libre

Note : Pensez bien à ouvrir le port utilisé sur le serveur cible

Créer une release

  • Connectez sur VSTS
  • Allez dans « Build & Realease »/Releases

Create_release_1

  • Cliquez sur « Create release definition »

Create_release_2

  • Sélectionnez Empty et cliquez sur Next
 Create_release_3
  • Sélectionnez votre projet
  • Sélectionnez la définition du build que vous avez précédemment créé
  • Cochez « Continuous Deployement », pour le déploiement s’exécute à chaque nouveau build.
  • Cliquez sur Create

Ajout de tâches

Maintenant que la release a été créé vide, il faut lui ajouter des tâches à exécuter.

Task_release_1.png

  • Modifier le nom de la Release : Interne
  • Liez la release à un package de déploiement :
    • Cliquez sur « Link to an artifact source « Link_to_artefact_release_2.png
  • Sélectionnez la queue de déploiement :
    • Celle que nous avons précédemment créée : Interne

Select_Queue_release_2.png

  • Cliquez sur « Add tasks » :
    • Windows Machine File Copy
      • Ajouter la tache « Windows Machine File Copy », afin de copier le package à déployer sur le serveur cible.Add_Task_Copy_files.PNG
      • Configurez cette tache de copie :
        • Sélectionner le fichier compresser dans le package précédemment lié,Select_Package_release_3
        • Select_Package_release_4
        • Select_Package_release_5
    • WinRM – IIS Web Deployment
      • Ajoutez la tache « WinRM – IIS Web Deployment »Add_Task_Web App Deployment
        • Si cette dernière n’est pas disponible, il faut ajouter l’extension à votre VSTS depuis le market Visual Studio ici.
      • Configurez la tache :
        • WinRM :
          •  Machines : Nom réseau du serveur cible
          • Admin Login/Password : Login et Password d’un compte admin sur le serveur cible
          • Protocol : Sélectionnez le protocole utilisez par le WinRM sur le serveur cible
        • Deploiement :
          • Web Deploy Package : Nom et chemin de copie du package de déploiement, définie dans la tache précédente
          • Website Name : Name du site web précédemment créé : InterneWebApp_release_.png
  • Allez dans l’onglet « Triggers » :
    • Cochez « Continuous Deployment »
    • Sélectionnez le nom du build à surveiller et pour quelle branche le build a été effectuéTriggers_release_.png

 

 

Héberger un package Nuget sur Team Services et l’alimenter depuis une build

Objectif : 

L’objectif de cet article est de vous présenter comment automatiser depuis Team Services la génération d’un ensemble de classes qui seront ajoutées dans un package NUGET hébergé sur TFS online.

Contexte : 

Une solution VS contient un ensemble de classes communes à plusieurs projets.
Ces classes sont regroupées dans des librairies que l’on veut pouvoir accéder depuis NUGET.

vso_nuget_sc1

Création du container sur VSTS : 

Pour créer le container, vous devez aller dans la section « Packages » du menu « Build & Release ». Si vous ne voyez pas le menu, c’est que vous devez préalablement sélectionner un projet.

vso_nuget_sc2

Si vous n’avez pas le menu package depuis votre interface, vous devez aller dans le MarketPlace et installer Package Management (https://marketplace.visualstudio.com/items?itemName=ms.feed)

Vous pouvez alors ajouter un « feed ». Nous vous conseillons de laisser les options par défaut pour le moment.

Une fois créé, il faut modifier les droits de ce dernier. Pour cela aller dans la section « Permission », et ajouter aux contributeurs les comptes « Project Collection Build Service » et « Project Build Service ». Ces deux comptes sont ceux qu’utilisera le Publisher Nuget lors de la Build.

De même vous pouvez restreindre les accès en lecture à certains groupes si vous le désirez.

vso_nuget_sc3

Le container est maintenant créé, il faut l’alimenter.

Création de la Build : 

Nous allons maintenant créer la Build qui générera le package et le mettra dans le feed. Pour cela aller dans Builds et Cliquer sur « New » et choisir une le template Visual Studio.

Dans les étapes, supprimer les modules « Publish symbols path », « Copy Files » et « Publish Articfact », et ajouter les tâches « Nuget Packager » et « Nuget Publisher ».

On peut commencer le paramétrage de chaque étape.

La première consiste à restaurer les packages Nuget nécessaires à la compilation des projets.
Pour cela on sélectionne le path du fichier solution .sln.

vso_nuget_sc4

On procède de la même manière sur l’étape de compilation.

Comme notre solution comporte des tests unitaires, nous laissons l’étape de tests. Ainsi, s’il y a une régression, la build sera en erreur et le package ne sera pas généré.

Concernant l’étape « Nuget Packager », il est possible de spécifier un fichier .sln ; toutes les dlls de la solution seront alors intégrées dans le package, ou préciser un fichier de configuration.
Pour ne pas ajouter des dlls inutiles (celles du framework, celles des librairies de tests), nous faisons le choix de sélectionner un fichier de configuration .nuspec. Ce fichier ajouté manuellement se trouve à la racine de la solution.
Voici le fichier actuellement utilisé :

<?xml version= »1.0″ encoding= »utf-8″?>
<package xmlns= »http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd »&gt;
<metadata>
<id>CommonLibraries</id>
<version>2.0.1</version>
<authors>MCNEXT</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<developmentDependency>true</developmentDependency>
<summary />
<releaseNotes />
</metadata>
<files>
<file src= »0-Services\bin\Debug\0-Entites.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Helpers.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Repository.dll » target= »lib » />
<file src= »0-Services\bin\Debug\0-Services.dll » target= »lib » />
</files>
</package>

Les données obligatoires sont l’id, le numéro de version et la liste des fichiers.
Le numéro de version est dans ce fichier une valeur fixe. Elle sera écrasée par la build à chaque incrément.

Voici le détail de la configuration :

vso_nuget_sc5

Remarquons que le package généré se trouvera dans le répertoire $(Build.StagingDirectory) et que nous automatisons le versionning en utilisant l’horodatage.

Enfin la dernière étape consiste à publier le package Nuget généré vers le container créé précédemment.
Nous précisons la localisation du package nuget à déployer, tout en supprimant les packages importés lors de la compilation ; le type de Feed, et l’url de ce dernier qui nous a été fournie lors de sa création.vso_nuget_sc6

 

La build est prête, vous pouvez la lancer pour générer votre premier package.

Maintenant nous allons voir comment l’utiliser dans vos solutions.

Importer le package Nuget dans son projet

La première étape est d’ajouter le container à Visual Studio.
Pour cela aller dans Visual Studio, Outils -> Options, ajouter la source de package avec l’url du feed.

Vous pouvez alors ajouter le package Nuget à votre solution/projet en utilisant le package manager de Visual Studio.

vso_nuget_sc8

Il est possible que pour l’installation ou les mises à jour vous ayez besoin de cocher « Include prerelease ».

Importer le package Nuget lors d’une build

Si votre projet consommateur du package Nuget généré est intégré à une build, il faut préciser à l’agent de Build comment récupérer le package pour compiler.

Pour cela, lors de l’étape de restauration du package Nuget, il ne faut pas préciser le path du fichier Solution (.sln) mais plutôt utiliser un fichier de configuration.

Dans chaque solution, nous avons normalement un fichier NuGet.Config dont nous modifions le contenu comme tel :

<?xml version= »1.0″ encoding= »utf-8″?>
<configuration>
<solution>
<add key= »disableSourceControlIntegration » value= »true » />
</solution>
<activePackageSource>
 <add key= »All » value= »(Aggregate source) » />
</activePackageSource>
<packageSources>
<add key= »nuget.org » value= »https://www.nuget.org/api/v2/ &raquo; />
<add key= »CommonLibraries_DEV » value= »https://monurl.pkgs.visualstudio.com/_packaging/CommonLibraries_DEV/nuget/v3/index.json »/&gt;
</packageSources>
</configuration>

Les informations à ajouter sont le paramètre activePackageSource où nous spécifions que nous voulons importer tous les packages.
Et bien sûr, le package à importer.

Dans la configuration d’une build d’un projet, le path est à préciser dans le champs « Path to Nuget.config »

vso_nuget_sc9

 

La build est paramétrée pour importer correctement le package Nuget créé en interne.

 

Nous venons de voir comment configurer un  package Nuget dans VSTS. Cette génération peut très bien être déclenchée dans le cadre d’une intégration continue.

Une étude plus approfondie peut être faite sur la génération du numéro de version pour éviter de rechercher les nouvelles versions du package en cochant ‘pre-release’.

Tricks : Gérer son numéro de version au niveau de la solution

Si comme moi, vous avez toujours rêvé de pouvoir gérer son numéro de version au niveau de solution et non au niveau de chaque projet cet article est fait pour vous !

Marche à suivre

  1. Click droit sur la solution -> Ajouter un nouvel item -> Classe Visual C#
  2. Nommez le fichier « SharedAssembyInfo.cs »
  3. Reprenez toutes les infos d’un « AssemblyInfo.cs » d’un projet existant et copier-coller le contenu dans « SharedAssembyInfo.cs ». Les fichiers « AssemblyInfos.cs » se trouvent dans la rubrique « Properties » située juste au-dessus de « Références ».
  4. Mettez en commentaire tout le contenu des différents « AssemblyInfo.cs »
  5. Sur chaque projet :
    1. Click droit -> Ajouter élément existant
    2. Sélectionner le « SharedAssembyInfo.cs »
    3. Choisir d’ajouter en tant que lien
    4. Faites glisser le fichier ajouté au projet dans le dossier « Properties »

A savoir

Vous n’êtes pas obligé de partager toutes les informations dans le « SharedAssembyInfo.cs », tout ce qui est spécifique à chaque projet vous pouvez le laisser dans le « AssemblyInfos.cs » du projet.

Pour allez plus loin

Savez-vous que vous pouvez générer un numéro de build sans usine de build depuis Visual Studio? Pour cela il suffit de :

  1. Mettre en commentaire l’attribut « [assembly: AssemblyFileVersion(« 1.0.0.0 »)]» que l’on trouve dans « SharedAssembyInfo.cs » ou « AssemblyInfos.cs ». Seul l’attribut « AssemblyVersion » doit être spécifié.
  2. Mettre l’attribut « AssemblyVersion » sous la forme : « [assembly: AssemblyVersion(« Majeur.Mineur.* »)] »

Après ça, à chaque build, Visual Studio va remplacer l’étoile par un « numéro de build » et un « numéro de révision » :

  • Numéro de build : Le nombre de jour depuis le 1er Janvier 2000.
  • Numéro de révision : Le nombre de secondes depuis minuit divisé par 2.

 

J’espère que cet article vous aura été utile 😉

 

Sources

http://weblogs.asp.net/ashishnjain/sharing-assembly-version-across-projects-in-a-solution

http://www.csharpcity.com/2012/visual-studio-automatic-version-numbering/

https://msdn.microsoft.com/en-us/library/k49w9389(v=vs.110).aspx

Microsoft Test Manager : Tester un Build

Dans la 1ère partie nous avons vu comment configurer un environnement de test pour Microsoft Test Manager. Nous allons maintenant nous intéresser à comment tester un build sur un environnement configuré et comment faire en sorte que toutes les données qui nous intéresse soient bien collectés, en l’occurence, les données de « Test Impact Analysis« . Ces données permettent de détecter quels tests rejoués en fonction des changement apportés aux code source !

Marche à suivre

  1. Configurer Test Manager pour qu’il se lance toujours en mode administrateur (sinon il n’aura pas les droits pour observer les autres process)
  2. Paramétrer Test Manager (testeur) pour qu’il utilise la configuration créée précédemment en Test settings et la machine où va être déployé l’application comme environnement :
  3. Queue un  XAML build, attendre qu’il finisse. Le premier build va permettre de constituer une base sur laquelle le moteur pourra analyser les différences avec les prochains builds. 
  4. Effectuer le déploiement
  5. Assigner le build au test, une pop-up vous proposant de voir les tests recommandés s’affichera. Assigner un build aux tests permet d’attacher les données de tests à ce build.
  6. Run le Test Plan
  7. Après avoir cliqué sur « Start Test » (pas besoin de coché « Create action recording »), lancer l’application en mode Administrateur afin que le processus tourne avec le même compte utilisateur.
    4
  8. Vérifier à la fin du 1er cas de test que les fichiers « testImpact.xml » et [webServer].testImpactXml sont bien mis en pièce jointe. S’ils ne sont pas présent regarder si vous n’avez pas des fichiers warning afin de déceler des erreurs. 

A Savoir

  • Aucune notification n’apparait si un problème a empêché la collecte d’informations nécessaire à l’analyse
  • Il ne supporte pas bien les multithread/méthodes asynchrone
  • Il détecte correctement le changement de code dans le XAML
  • Test Impact Analysis n’existe pas encore avec le nouveau système de build vNext.
  • Il est préférable qu’un seul application pool utilisant le compte de service tfs et que celui-ci n’ai qu’un seul site web.
  • Le démarrage d’une suite de tests redémarre le serveur IIS

 

Cette procédure fonctionne aussi pour les autres données de tests que l’on peut collecter et rattacher à un build. A ce propos, il faut savoir que pour les données de couverture de code nécessite de labelliser les sources lors du build.  Les données de tests récoltés sont consultables sur le résumé du build dans le portail web tfs (et l’interface est plutôt bien fait !)

J’espère que cette série vous en a appris plus sur les fonctionnalités de Microsoft Test Manager 🙂

Microsoft Test Manager : Créer et utiliser un environnement de Test

Vous connaissez peut-être Microsoft Test Manager, l’outil de Microsoft dédié aux testeurs. Sachez qu’en plus de l’organisation de cas de tests, cet outil permet aussi de collecter des données durant les tests notamment :

  • Les informations système (OS, Naviguateur)
  • Les évènements systèmes
  • Les events Intellitrace
  • La couverture de code du test
  • Les actions utilisateurs (bouton cliqué, texte saisie, etc)

Ces données peuvent tout aussi bien être collectés côté client que côté serveur ! Et quand je dis côté serveur c’est que l’applicatif arrive à tracer les requêtes effectuées au site web IIS faisant tourner vôtre API !

Pour collecter côté client, rien de plus simple le Test Runner intégré à Microsoft Test Manager se charge de tout, mais pour collecter côté serveur, cela nécessite une bonne dose de configuration que nous allons voir ensemble. Dans ce tutoriel nous allons créer un environnement de test pour une application composée d’un client WPF communiquant avec une WebApi.

Cette série de posts sur « Microsoft Test Manager : Créer et utiliser un environnement de Test » sera composée en 2 partie :

  1. Créer un environnement de Test
  2. Tester un build dans un environnement de test

Prérequis :

  • TFS XAML Build
  • License Visual Studio Enterprise ou Test Professionnal
  • 1 application avec du code managé pouvant être traduit en Common Intermediate Language
  • Un compte de domaine TFSTEST
  • Un serveur où seront déployées les applications à tester : TFSTESTSERVEUR
  • Télécharger l’ISO des derniers agents pour Visual Studio 2013 (en effet les agents 2015 ne sont pas compatibles avec Lab Center / Test Manager)
  • Microsoft Test Manager installé sur le poste du testeur
  • Des campagnes de tests dans Microsoft Test Manager

Pour installer le contrôleur et les agents vous pouvez choisir :

  • D’installer le contrôleur sur votre machine de build et les agents sur TFSTESTSERVEUR
  • D’installer le contrôleur sur la machine faisant tourner TFS Web App et les agents sur TFSTESTSERVEUR
  • D’installer le contrôleur et les agents sur TFSTESTSERVEUR

 

Le compte TFSTEST doit être ajouté au groupe administrateur des serveurs où sont installés le contrôleur et/ou les agents (notamment TFSTESTSERVEUR)

L’environnement de test sera ici un « environnement standard » et non un « environnement virtuel »

 

Installer et configurer le Test Contrôleur

  1. Monter l’ISO et à partir du dossier TestController et installer le contrôleur sur TFSTESTSERVEUR.
  2. Le configurer pour qu’il tourne avec le compte TFSTEST et le connecter à la bonne « Collection de projets d’équipe »

image001

  1. Cliquer sur « Appliquer»

 

Installer les agents sur TFSTESTSERVEUR

  1. Monter l’ISO et à partir du dossier TestAgent installer l’agent de test
  2. Configurer l’agent de test pour qu’il tourne avec le compte TFSTEST et l’enregistrer auprès du contrôleur précédemment installé.
  3. TODO Screenshot
  4. Cliquer sur Appliquer

Pour plus d’infos n’hésitez pas à consulter : https://msdn.microsoft.com/en-us/library/hh546460.aspx

 

Créer l’environnement avec Microsoft Test Manager

  1. Allez dans Lab Center puis choisissez l’onglet Contrôleur, vérifiez que votre contrôleur est en ligne.image003
  2. Allez dans l’onglet « Lab », cliquer sur « Nouveau »image005
  3. Etape « Type et nom » : Choisir « Environnement standard » et attribuer un nom
  4. Etape « Ordinateurs » :
    1. Ajouter TFSTESTSERVEUR
    2. Saisir les identifiants du compte TFSTEST
    3. Choisir le type Web Server
  5. Etape « Propriétés de l’ordinateur» : ras
  6. Etape « Avancée » : ras
  7. Etape « Vérification » : Cliquer sur « Vérifier », si tout se passe bien l’environnement devrait être créé.
  8. Cliquez sur « Terminer», l’outil va installer les agents et les configurer sur TFSTESTSERVEUR

Pour plus d’infos n’hésitez pas à consulter :  https://msdn.microsoft.com/en-us/library/ee390842.aspx

 

Créer la configuration de Test avec Microsoft Test Manager

  1. Dans «Lab Center», aller dans « Paramètres de tests » et cliquer sur nouveau
    1. Etape « Général» : Saisir un nom, une description et choisir le type « Manuel »
    2. Etape « Rôles » : Choisir Serveur Web
    3. Etape « Données et Diagnostics » : image008
    4. Etape « Résumé » : Cliquer sur Terminer

 

Et voilà, la configuration de l’environnement est enfin terminée ! A présent vous allez pouvoir collecter les données dont vous avez besoin aussi bien côté client que côté serveur ! Dans le prochain post nous verrons comment rattacher ces données de tests à un build, ce qui va notamment permettre d’utiliser une fonctionnalité unique de TFS, Test Impact Analysis (un algorithme permettant de calculer les tests à rejoués entre 2 builds !).

[NCrafts] Continuous delivery, the missing parts

Paul Stack commence cette présentation avec une définition du Continuous Delivery (déploiement continue), qui est composé de principes et de pratiques pour construire, tester , deployer plus rapidement et plus fréquemment.

Les principes:

  1. Le processus doit être répétable et fiable
  2. Tout tâche soit être automatisée
  3. Si quelque chose est difficile, le faire plus souvent
  4. Tout mettre dans un contrôleur de source
  5. Le done (terminé) s’applique à une fonctionnalité livrée
  6. La qualité doit aussi être présente dans le code
  7. Tout le monde est responsable du processus de déploiement
  8. Le processus doit être constamment éprouvé

Lire la suite

[TechDays 2015] Introduction à DevOps

Aujourd’hui les systèmes d’information sont constitués de plusieurs protagonistes : les développeurs, les administrateurs, les manageurs, les testeurs et intégrateurs, et les administrateurs de bases de données.

La problématique que nous rencontrons c’est un mauvais échange ou bien même parfois aucun entre les développeurs (dev) et l’équipe infrastructure (ops) qui est du à un vocabulaires et couches métiers différentes, ce qui conduit à une mauvaise qualités de projets en production ou de livraison.

Qu’est ce que le DevOps

Inventé en 2009 DevOps qui est la concaténation de dev(developpeurs) et ops (opérations =  exploitation) est une philosophie organisationnelle visant à réduire les frictions entre les dev et l’IT (ops) et ayant pour but de faire un projet ensemble.

A qui s’applique t-il

Il peut s’appliquer :

A de multiple type de secteur: web / mobilité, industrie, éditeur de logiciel, founisseurs de services cloud, jeux.

A toute organisation : petite structure (communication plus facile) mais aussi dans les grandes structures (comme Facebook, Linkin, Microsoft, Amazon).

Et pour tout type d’applications : web , mobile, jeux.

Par contre DevOps est moins adapté aux applications de type Client/Serveur (du au déploiement qui se font moins en continue). Lire la suite