[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

Microsoft Ignite 2015 – Du lundi 4 mai au Mercredi 6 mai par Stéphane

Par Stéphane,
Pôle SharePoint MCNEXT

LUNDI 4 MAI 2015
1 – DevOps as a strategy for business agility
2 – Deep Div into Safe Sharepoint Branding in Office 365 Using Repeatable Patterns and Practices
3 – Building solutions with Office 365

MARDI 5 MAI 2015
4 – Get Your Hands Dirty with the Office 365 APIs, Authentication, and SDKs
5 – Designing and Applying Information Architecture for Microsoft SharePoint and Office 365
6 – Building business apps like they do in the valley with Angular, Node.js, and more..

MERCREDI 6 MAI 2015
7 – Understanding the IT Pro’s dynamic operations role within DevOps
8 – What’s new for build automation in Team Foundation Server and Visual Studio Online
9 – Bose Turns Up the Volume with Microsoft Office 365
10 – Visual Studio 2015 for Web Developers
11 – Implementing Next Generation SharePoint Hybrid Search with the Cloud Search Service Application

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

Techdays 2015 : Review de la session « Docker, une alternative aux machines virtuelles pour déployer ses services .Net »

Docker : Késako ?

Docker permet d’embarquer une application dans un container virtuel qui pourra s’exécuter sur n’importe quel serveur (Linux et bientôt Windows). C’est une technologie qui a pour but de faciliter les déploiements d’une application, et la gestion du dimensionnement de l’infrastructure sous-jacente. Cette solution est proposée en open source (sous licence Apache 2.0) par une société américaine, également appelée Docker, qui a été lancée par le Français Solomon Hykes.

Voici un slide comparant la même infrastructure utilisant Docker et des VM.

dockerVSVm

Comme vous pouvez le constater cela permet d’éviter de dupliquer les couches (notamment celle de l’OS Hôte !) par rapport à une architecture à VM. Les blocs sont versionnés et ne sont pas dupliqués sur l’hôte :

  • Sur l’architecture à VM on a 3 VM avec 3 blocs (9 blocs)
  • Sur l’archi Docker on a que 5 conteneurs car Lib 1 a été mutualisé entre les « App 1 » et « App 2 ». L’OS Hôte est un OS minimaliste comme CoreOs qui n’embarque que les fonctionnalités essentielles pour accueillir un conteneur, si l’application nécessite un composant (comme un hôte de site web)cela sera compris dans ses conteneurs en dessous de lui.

D’un point de vue d’un développeur C# cela s’apparente un peu à un package Nuget mais au lieu d’être au niveau de la solution c’est au niveau du serveur.

Docker crée le conteneur à partir d’un Dockerfile contenant les instructions pour cette image, en voici un exemple :

dockerfile

  • FROM : Image de départ (un conteneur est créé à partir du conteneur en dessous de lui)
  • ADD : Ajoute ce qu’il y a dans le dossier src vers le dossier /app/
  • WORKDIR : Déplace l’environnement de travail (où sont traités les commades) vers le dossier app
  • RUN : lance la commande kpm restore qui télécharge tous les paquets nécessaires
  • EXPOSE : Indique à Docker que le conteneur va écouter sur ce port
  • ENTRYPOINT : Permet d’indiquer qu’un conteneur est un exécutable. Dans ce cas-ci on va utiliser kestrel (web server linux) pour faire tourner l’app.

Plus d’infos à ce sujet ici : https://docs.docker.com/reference/builder/

 

.Net avec Docker

Pour .Net ce n’est pas actuellement Production Ready, en effet .Net Core est encore en bêta sur Linux et Docker n’est pas dispo sur Windows Server 2012 (mais le sera sur la prochaine version de Windows Server). Une config standard pour tester Docker est d’avoir une machine virtuelle Linux tournant sur un poste Windows (qui fait tourner Visual Studio) :

dockerDevOps

Une configuration plus précise pour la partie Dev :

devWithDocker

Le développeur utilise un share entre sa VM Linux et son Windows. La VM tourne grâce à Hyper-V. On voit ici qu’actuellement faire du .Net avec Docker est un peu compliqué et que de manière général ça manque de tooling (beaucoup de lignes de commandes).

 

Bonne nouvelle : Demain ce sera plus simple on pourra le faire tourner sur un Windows Server, plus d’infos ici.

dockerDevFutur

 

A savoir

  • L’ops peut reconfigurer certains paramètres (ports si la même appli existe sur le même hôte).
  • Docker possède un cache pour ne pas re-télécharger l’image.
  • Pour le moment Docker ne gère rien côté sécurité, il ne fait aucun check pour savoir si l’image obtenue est bien celle demandée mais c’est prévu.
  • Une best practice est de créer un conteneur coquille utilisée par toutes les applications de l’entreprise.