C'est quoi un Ingénieur d'Intégration Continue

L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de construire des voitures, on construit un logiciel. Un logiciel est modifié sans cesse et pour sécuriser son processus de fabrication, il faut automatiser le plus possible sa fabrication.

En 2013, j'écrivais déjà un article sur l'intégration continue : Outils d'Intégration Continue

Attention l'intégration continue s'entend souvent sur multiplateformes une partie des développements viennent de Windows et peut être qu'une autre partie vient de Linux, il faudra évoquer CMake.

Pour découvrir rapidement CMake :

Alexandre Laurent - Développez.com - Utiliser CMake pour compiler un projet

Etape par étape, je vais détailler les outils correspondants au métier de l'Ingénieur d'intégration continue. Dans les équipes de développement une personnes est dédiée à l'intégration continue. C'est ce qui différencie un développement artisanal d'un véritable développement professionnel. 

Alors quelles sont les spécificités de ce métier ? Quelles sont les nouveautés de ces dernières années.

Ingénieur d'intégration continue définition de poste

Je débute par une définition de poste voilà ce que je propose :

Collaborer avec les experts techniques R&D (architectes logiciel et experts métier) et les utilisateurs (équipes de qualification des produits) pour comprendre les exigences métier et identifier les solutions d’intégration et déploiement automatisés et de validation automatique de nos produits logiciels.

Il s'agit bien sûr d'une très grosse société au sein d'une très grosse équipe. Là on se rend compte que l'intégration continue n'a pas pu être mise en œuvre, il faut donc un facilitateur.

Et l'on donne l'outil Jenkins

Nous y voilà, nous avons une parfaite connaissance d'MSBuild on y ajoute les Outils d'Intégration Continue et au dessus de tout ça l'outil Jenkins va nous permettre de faire quoi ?

Jenkins Documentation Use-cases - C/C++

Jenkins Définition

Jenkins est un serveur d'automatisation open source autonome qui peut être utilisé pour automatiser toutes sortes de tâches liées à la création, au test, à la livraison ou au déploiement de logiciels.

Jenkins Installation

Jenkins est une application web à laquelle on accède par localhost une fois installée.

Jenkins - Getting started with the Guided Tour

La suite consiste à créer des pipeline des canaux de livraison continue. L'objectif de Jenkins est de pouvoir enchaîner les différentes étapes pour construire tester et déployer l'application.

Vous maîtrisez un outil comme Jenkins vous êtes un Ingénieur d'Intégration Continue.

Vous avez maintenant tout le loisir de vous former à Jenkins. Je voudrais aborder une notion importante de Jenkins c'est Blue Ocean dit comme ça c'est flou mais Blue Ocean vient se mettre au dessus de Jenkins et permet de repenser l'expérience utilisateur de Jenkins. Blue Ocean est un éditeur de pipeline.

En suite, je pense faire un tour du côté de ce site :

Continuous Integration with MSBuild and Jenkins – Part 1

Et puis un petit retour sur la doc Jenkins et l'intégration de MSBuild Plugin pour l'intégration continue sur plateforme Windows :

Jenkins - MSBuild Plugin

Car MSBuild cela je connais bien :

MSBuild - Outils d'intégration continue

Donc un Ingénieur d'intégration continue ce serait quelqu'un qui maîtrise aussi bien MSBuild que Jenkins. Ce blog est donc l'outil pour devenir un Ingénieur d'Intégration Continue.

C'est quoi Ansible ? IT automation tool ?

On est dans le vif du sujet, la prolifération des outils de développement logiciel est faramineuse et leurs noms n'évoquant absolument rien il est bien difficile mémotechniquement de retenir tout ça. Alors Ansible c'est quoi ?

Je cherche un peu, je tombe bien directement sur la documentation : Doc Ansible
 

Documentation Ansible

Et si on en croit la documentation c'est un outils d'automatisation des tâches de l'intégration continue avec un temps nul de retour en arrière. Autrement dit si un erreur est détectée durant le déploiement d'une nouvelle release on peut retrouver rapidement l'état précédent de fonctionnement correcte.

Et dans la doc :

Control Machine Requirements
Currently Ansible can be run from any machine with Python 2 (version 2.7) or Python 3 (versions 3.5 and higher) installed. Windows isn’t supported for the control machine.
This includes Red Hat, Debian, CentOS, macOS, any of the BSDs, and so on.

Dommage !


Une belle vidéo :

With Ansible - Solve IT, Automate IT, Share IT

On dirai que c'est un peu lié à la distribution Linux Red-Hat :

Ansible & RED HAT

Ansible is a Tower.

Oui mais ce n'est pas pour Windows. Encore que : Ansible Windows Guide

A creuser !


Connaissez-vous Kubernetes ? Outil du DevOps

Parmi les outils du DevOps voici Kubernetes, un outil qui a le vent en poupe. Intéressons nous aux fonctionnalités qu'il procure. Cet outil permet de gérer les applications mises en containers.

Les outils du DevOps Kubernetes

Définition : Kubernetes est un système open source permettant de gérer des applications contenairisées sur des hôtes multiples. Il fournit des mécanismes de base pour le déploiement, la maintenance et la mise à l'échelle (scale up) d'applications.

Ce projet open source est hébergé par le Cloud Native Computing Foundation (CNCF).

J'ai trouvé à travers la documentation quelque graphiques simples pour présenter cet outil :

Learn Kubernetes Basics

Qu'est-ce que Kubernetes peut faire pour nous ?

Avec les services Web modernes, les utilisateurs s'attendent à ce que les applications soient disponibles 24 heures sur 24, 7 jours sur 7, et les développeurs s'attendent à déployer de nouvelles versions de ces applications plusieurs fois par jour. 

La containeurisation aide les progiciels à atteindre ces objectifs, permettant ainsi aux applications d'être publiées et mises à jour de manière simple et rapide, sans temps d'arrêt.

Kubernetes vous aide à vous assurer que ces applications containeurisées s'exécutent où et quand vous le souhaitez et les aide à trouver les ressources et les outils dont elles ont besoin pour fonctionner.

Kubernetes est une plate-forme open source prête pour la production, conçue avec l'expérience accumulée de Google dans l'orchestration de conteneurs, associée aux meilleures idées de la communauté.

Kubernetes Basics Modules - Basic workflow

1. Créer un cluster Kubernetes
2. Deployer une application
3. Explorer votre application
4. Exposer votre application publiquement
5. Scale up votre application
6. Mettre à jour votre application

Voilà c'est tout pour l'instant, je garde en tête le nom de cet outil et s'il permet de faire facilement tout cela. Dans le cadre du DevOps, il est indispensable d'automatiser toutes les tâches possibles pas seulement pour gagner du temps mais pour supprimer les erreurs humaines également.

J'ai passé du temps à recueillir ces informations et pourtant ce n'est pas exhaustif, je ne sais même pas sur quelle plateforme cet outil s'installe !

Mise à jour, de plus en plus de client cherchent des compétences sur Kubernetes

Je me suis retrouvé dans un Bootcamp :

kubernetes bootcamp 1

La seule commande que j'ai su taper c'est :

>exit

En fait, il faut cliquer sur les commandes dans la fenêtre de gauche sous "Cluster up and running" et vous verrez les commandes :

>minikube version

>minikube start ...

Vous avez alors les commandes qui s'exécutent et affichent leur déroulement dans la console.

Kubernetes dans le Cloud Azure de Microsoft

Je trouve toute une littérature sur le sujet, sur le site de Microsoft je trouve :

Kubernetes dans le Cloud Azure

Microsoft - Azure Kubernetes Service (AKS)

AKS réduit la complexité et les coûts opérationnels liés à la gestion de Kubernetes en déléguant une grande partie de cette responsabilité à Azure.

Beaucoup de blabla, pas de cas pratique, beaucoup de liens vers d'autres technos. C'est normal, la complexité de Kubernetes ne s'appréhende pas en une demi-journée.

J'ouvre mon portail Azure et je cherche Kubernetes, je trouve "Kubernetes - Azure Arc", alors Azure Arc c'est quoi ? ... Ils appellent cela : Hybride et multicloud

Il me faut creuser encore ...

Outils d'intégration continue

Quand on a pratiqué l'intégration continue entièrement intégrée avec Team Foundation Server, on est un peu désarçonné par l'ensemble de tous les outils qui peuvent être utilisés afin de mettre en place une stratégie d'intégration continue avec d'autres chaînes de développement que TFS. 

Cet article est là pour faire un petit récapitulatif de ce qu'est l'intégration continue.

Team Foundation Server

Les principes d'intégration continue permettent de distinguer un développement artisanal d'un développement industriel ou développement maîtrisé de façon professionnelle.+

En intégration continue, vous avez forcément un serveur dédiée sur lequel le produit logiciel est déployé afin de faire une vérification complète du produit avant de déployer sur une cible finale, ce n'est pas le cas dans le cadre d'un développement artisanal.

Les Principes de l'Intégration Continue

• le code source est partagé et versionné dans un gestionnaire de code source (un référentiel ou repository unique)
• les développeurs intègrent (commit ou checkin) leur code le plus souvent possible (chaque jour par exemple)
• des tests unitaires sont développés et des tests d'intégration permettent de valider l'application sur un serveur d'intégration (ou serveur de build)

La mise en place de ces principes permet de :

• tester immédiatement les unités modifiées et leur compatibilité entre elles
• découvrir immédiatement des codes manquants ou incompatibles
• les problèmes d'intégration sont réparés pour éviter les problèmes de dernière minute
• une version est toujours disponible pour un test une démonstration ou une distribution

Qu'est ce que l'intégration continue sur le site de So@t

Intégration continue des bases de données : RedGate avec SQL Toolbelt comparaison de schémas de base de données. BD SQL Server ou Oracle.

Team Foundation Server pour :
Gestion de Projet
Gestion de prérequis
Versionnement de code source
Gestion de cas de test
Automatisation de build
Génération de rapports

Configuration du serveur TFS : Team Server Foundation en pas à pas

Sur le Blog de Julien Carnelos : L'intégration continue Open Source en .NET

Principe : Tout ce qui peut-être automatisé doit l'être.
Contrôle de codes sources : SVN (Subversion)
Tests Unitaires : NUnit
Compilation et Build : NAnt
Contrôle de construction : CruiseControl.NET et CCTray

Pour aller plus loin : Mise en place d'outils d'analyse de codes sources de génération de métriques. Terminer le Build NAnt par la génération d'un package d'installation prêt pour la livraison. L’envoi d'un email de notification à un client ou mieux à une équipe de QA (Assurance Qualité).

Je me propose de recopier ici quelques bonnes phrases du blog de J.Carnelos car les liens cassent ...

On oppose généralement l’aspect industriel du développement à l’artisanal. Pour mieux saisir la signification de ce terme, je vous propose une petite histoire :

Après quatre mois de développement, c’est le grand jour de la livraison. Georges, après avoir testé une dernière fois que son code compile, décide de déployer la version finale du site Intranet de la mairie. La démarche est maîtrisée puisque cela fait maintenant une vingtaine de fois qu’il a répété l’opération. Comme à chaque fois, il commence par demander à son collègue sur quels fichiers il a travaillé. La liste connue, il récupère par le réseau ces fichiers, puis tente de compiler le projet. Chance, tout compile.

La suite est plus délicate, Georges doit se connecter à distance au serveur, migrer la base de données et insérer les données mis à jour. Vient ensuite la partie copie des fichiers sur le serveur et redémarrage du serveur. A ce moment, si tout va bien, le site devrait être mis à jour. Malheureusement, au premier test, impossible de se logger.

Si cette scène vous rappelle quelque chose, pas d’inquiétude car c’est courant et aujourd’hui de nombreuses sociétés fonctionnent dans ce mode de gestion. Mais l’industrialisation et l’automatisation sont maintenant un but plus facile que jamais à atteindre grâce à de nombreux outils. Preuve en est également l’implication de Microsoft sur le thème « Gestion du cycle de vie logiciel » et la fourniture d’une offre complète avec la suite Team System et son serveur Team Foundation Server.

Néanmoins pour des raisons de simplicité, nous nous attacherons ici à présenter les concepts de l’intégration continue à l’aide uniquement d’outils open-source.

Concept

Schéma d'une chaine d'intégration continue

L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de construire des voitures, on construit un logiciel. Cette « usine » est construite sur enchaînement suivant :

1. Un développeur travaille en local. Lorsque ses modifications sont terminées, il archive son code sur un serveur gestionnaire de sources.
2. A la détection d’un changement (ou suivant une règle temporelle paramétrée), le serveur d’intégration récupère la dernière version des sources et déclenche la construction (« build ») de la solution.
3. En étape facultative mais intéressante, il est possible d’appliquer des métriques et des tests sur la solution et d’en générer des rapports
4. Enfin, la solution et le bilan de la construction sont déployés sur un serveur de résultat accessible à l’équipe projet. Dans le cas d’un sous traitance, ce portail peut aussi être mis à la disposition du client pour qu’il puisse constater l’avancement du projet. (Particulièrement utile dans le cadre d’une démarche agile).

Documentation des codes sources

On ne crée pas de bons codes sources sans bonne documentation.

NDoc : Open Source Documenter, Générateur de documentation pour .NET

Sous TFS : SharePoint, oups ce n'est pas aisé d'utiliser cet outil que je trouve un peu archaïque

Outils d'analyse des codes sources

Fédérer une équipe autour d'un développement passe par le partage d'un certain nombre de bonnes pratiques, on appelait cela les coding guidelines aujourd'hui des outils permettent d'automatiser cette tâche en analysant les codes sources.

StyleCop : analyse syntaxique du code source C# sur le CodePlex : StyleCop

StyleCop provides value by enforcing a common set of style rules for C# code.

ReSharper de JetBrains : payant

Un outil d'analyse de code dans Visual Studio Express 2012

FxCop : curieux on note Framework 2.0, semble ne plus exister

Contrôle de codes sources, gestionnaire de versions

C'est un serveur, un endroit centralisé pour récupérer les codes sources créés par les développeurs, un outil permettant de versionner. Permet de résoudre les conflits de réaliser un merge entre plusieurs développements.

Outils :

TFS

SVN ou Subversion

CVS

Git

Perforce 

Tests Unitaires

Il existe MSTest mais il semble que cet outils de tests unitaires soit maintenant supplanté par NUnit ...

MSTest vs. NUnit with Visual Studio 2010 & TDD

NUnit vs xUnit parmi les modules de Tests Unitaires lequel choisir ?

Sur la plateforme .NET : NUnit

Sur le site du code project, rapidement comprendre NUnit : Unit Testing Using NUnit

NUnit permet d'écrire des tests unitaires du genre :

Assert.AreEqual(expected, actual)

NUnit permet l'utilisation de Mock Objects (simulateur d'objets)

A priori le projet NUnit n'est plus hébergé sur source forge mais Ici

Serveur d'intégration ou serveur de builds

C'est un élément clef de l'intégration continue souvent manquant dans les organisation "amateurs".

Les opérations à effectuer grâce aux outils de builds sont :

Nettoyer le répertoire de sortie (les binaires)

Compiler le code source

Exécuter les tests unitaires

Exécuter le programme

Mais aussi :

zip de fichier

transfert ftp

redémarrage de serveur web

En partant des sources, effectuer toute la livraison jusqu’à l’étape déployable (ou même déployé).

Intégration continue avec Team Foundation Server
MSBuild

NAnt qui possède l'avantage d'être multi-plateforme, s'exécute en ligne de commande et prend en paramètre un fichier XML qui décrit les différentes étapes pour emmener le code source dans l'état prêt à l'exécution.

CruiseControl.NET

TeamCity : de JetBrains

For .NET :

Building Visual Studio solutions; native support for MSBuild, Powershell or NAnt
Code analysis for C#, VB.NET, XAML, and many other languages powered by ReSharper
Testing with .NET testing frameworks, including: NUnit, MSTest, MSpec, xUnit and all Gallio-based frameworks
Code coverage with dotCover, NCover or PartCover
Best-in-class NuGet support

Je compléterai plus tard ... vous avez des suggestions d'amélioration et de complétion de cet article, n'hésitez pas à le commenter. Vous avez compris l'intégration continue concerne toutes les phases de développement du logiciel et l'utilisation des outils qui permettent d'automatiser tout ce qui peut l'être.

To Be Continued

Moteur de Build Microsoft : MSBuild Engine (1)

MSBuild, est un outil de génération d'applications. Il utilise un schéma XML pour contrôler la génération de produits logiciels. Visual Studio utilise MSBuild mais MSBuild ne dépend pas de Visual Studio.

En appelant MSBuild sur un fichier projet ou solution, vous pouvez orchestrer ou générer des produits dans des environnements où Visual Studio n'est pas installé.

Dans les fichiers projets (.csproj) vous trouverez le code XML MSBuild qui s'exécute lorsque l'on génère l'application.

Ainsi vous pouvez modifier le système de génération et :

• Prétraitez les fichiers avant qu'ils atteignent le compilateur.
• Copiez les sorties de génération vers un autre emplacement.
• Créez les fichiers compressés les sorties de génération.
• Effectuez une étape de post-traitement. Par exemple, vous pouvez emboutir un assembly avec une version différente.

Exemple d'utilisation : Utiliser Visual Studio sur un ordinateur de développement pour écrire le code XML de MSBuild  à l'aide de l'IDE, puis transmettre ce code aux autres développeurs qui l'exécuteront en ligne de commande afin d'intégrer votre développement.

MSBuild est utilisé dans le cadre d'une stratégie d'intégration continue.

On trouve MSBuild.exe dans les répertoires :
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
C:\WINDOWS\Microsoft.NET\Framework\v3.5

Egalement avec l'installation du Framework 4.5

Allez plus loin Ici.

Procédure pas à pas d'utilisation de MSBuild

Création d'un projet MSBuild et examen du fichier projet

Vous créez un projet avec Visual Studio, en suite pour éditer le fichier .csproj vous devez "Décharger  le projet" puis en cliquant bouton droit vous pourrez éditer, modifier le fichier .csproj.

Les fichiers XML MSBuild ont un noeud racine : "Project"

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="4.0" DefaultTargets="Build"  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Notion de Tâche MSBuild

Une tâche est la plus petite unité de travaille (l'atome) d'une build.

Les tâches MSBuild fournissent du code exécuter pendant le processus de génération. Chaque tâche est implémentée dans une classe .NET qui dérive de l'interface ITask.

Une bibliothèque de tâches courantes est fournit avec MSBuild mais pour écrire vos propre tâche il y a deux approches :

• Implémentez l'interface ITask directement.
• Dérivez votre classe de la classe d'assistance, Task, qui est définie dans l'assembly Microsoft.Build.Utilities.dll. La tâche implémente ITask et fournit des implémentations par défaut de quelques membres ITask. En outre, la journalisation est plus facile.

Exemple code C# :

using System;

using Microsoft.Build.Framework;

using Microsoft.Build.Utilities;

namespace MyTasks

{

    public class SimpleTask : Task

    {

        public override bool Execute()

        {

            return true;

        }

    }

}

Le fichier projet qui exécute cette tâche :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <Target Name="MyTarget">

        <SimpleTask />

    </Target>

</Project>

Allez plus loin Ici

Pour exécuter une tâche, MSBuild a besoin de mapper la tâche sur l'assembly qui contient son implémentation à l'aide de UsingTask.

<UsingTask TaskName="TaskName"

    AssemblyName = "AssemblyName" 

    TaskFactory = "ClassName"

    Condition="'String A'=='String B'" />

Notion de Cible MSBuild

Une cible est une séquence nommée de tâches.

Déclaration des cibles dans le fichier projet

<Target Name="Construct">

    <Csc Sources="@(Compile)" />

</Target>

Cibles prédéfinies :

<Target Name="AfterBuild" >
   <Message Text="First occurrence" />
</Target>
<Target Name="AfterBuild" >
   <Message Text="Second occurrence" /> 
</Target>

Dans ce cas uniquement la "Second Occurence" sera exécutée car MSBuild n'exécute qu'une fois une cible unique.

Ordre de génération des cibles

• Cibles initiales
• Cibles par défaut
• Première cible
• Dépendances cible
• BeforeTargets et AfterTargets (MSBuild 4.0)

Allez plus loin Ici.

Traitement par lots des cibles

Une cible peut avoir un attribut Outputs qui spécifie des métadonnées, dans ce cas, MSBuild exécute la cible une fois pour chaque valeur de métadonnées unique, en regroupant ou en "traitant par lot".

Exemple :

<ItemGroup>

    <Reference Include="System.Core">

      <RequiredTargetFramework>3.5</RequiredTargetFramework>

    </Reference>

    <Reference Include="System.Xml.Linq">

      <RequiredTargetFramework>3.5</RequiredTargetFramework>

    </Reference>

    <Reference Include="Microsoft.CSharp">

      <RequiredTargetFramework>4.0</RequiredTargetFramework>

    </Reference>

</ItemGroup>

<Target Name="AfterBuild"

    Outputs="%(Reference.RequiredTargetFramework)">

    <Message Text="Reference:

      @(Reference->'%(RequiredTargetFramework)')" />

</Target>

Donne à l'exécution :

   Reference: 3.5;3.5

   Reference: 4.0

Builds incrémentielles

Pour améliorer la vitesse de génération MSBuild utilise un mécanisme de build incrémentielle pour n'exécuter que les mises à jour. Un élément est considéré comme à jour si son fichier de sortie a la même ancienneté ou est plus ancien que son ou ses fichier(s) d'entrée.

Allez plus loin Ici.

Génération de la cible

On exécute MSBuild dans l'invite de commande de Visual Studio :

Dans le fichier myProject.csproj :

<Target Name="HelloWorld">
  <Message Text="Hello"></Message>
  <Message Text="World"></Message>
</Target>

En ligne de commande :

>msbuild myProject.csproj /t:HelloWorld

L'exécution avec le commutateur /t trouve la cible HelloWord et l'exéctute en sortie dans la fenêtre de commande on obtient :
Hello
World

Allez plus loin Ici.

MSBuild autres caractéristiques

Création de Tâches Inline Ici.

Quelques limitations de MSBuild

optimisé et facile d'utilisation qu'en association avec Visual Studio.

manuellement pénible et long d'écriture fichier dû au temps d'apprentissage de la syntaxe ...

les paramètres sont tous globaux.

plusieurs possibilités de référencer un item ou la valeur d'une propriété

la qualité de la documentation (semble s'être améliorée ...)

On parle de Ant ou NAnt également de GNU Make.

Nouveauté de la version MSBuild 4.5

Vous pouvez spécifier qu'une tâche s'exécute "out-of process" pour cibler un autre framework.net.

Vous pouvez générer des binaires qui ciblent un processeur ARM.

L'attribut d' ToolsVersion pour déterminer la version de l'ensemble d'outils MSBuild.

Nouveaux éléments du langage :

VisualStudioVersion

DoesTaskHostExist

Item

   KeepMetadata

   RemoveMetadata

   KeepDuplicates

ContinueOnError

   <Delete Files="@(Files)" ContinueOnError="WarnAndContinue"/>

   WarnAndContinue

   ErrorAndContinue

   ErrorAndStop