air - User contributions [en]

File:Proj-2014-2015-iRock-poster.pdf

2015-03-30T22:31:51Z

RICM4-prj14-grp11:

Proj-2014-2015-iRock/Scrum

2015-03-24T21:38:50Z

RICM4-prj14-grp11: /* Sprints */

Encadrant : Didier Donsez, <br>
Etudiants RICM5 :
* PEYRE Flavien (Chef de projet)
* BOEY Lionel (Scrum Master)
* GINOUX Pierre-Henri
* GUO Tianming

== Présentation de l'organisation du projet ==
Ce projet consiste de 4 étudiants de la filière RICM 5, dont un chef de projet et trois développeurs. La durée d'un sprint est fixé à une semaine vu la taille de notre projet et la dynamicité des technologies à évaluer dans le cadre du projet.

A priori, le développement est divisé en 2 parties : la partie embarqué (GUO et BOEY) et la partie visualisation (PEYRE et GINOUX). Pour la partie embarqué, nous nous sommes servi de plusieurs IDE pour programmer les micro-controllers notamment:
* Keil MDK 4 et 5 pour Windows
* Mbed
* Waspmote IDE
* ARM GNU Toolchains plugin sous Eclipse
* STM32 Cube

Au niveau backend(visualisation), nous avons utilisé le langage Python pour manipuler les données reçues et ensuite les stocker sur une base de donnée temporelle (InfluxDB et Grafana).

Dans tous les cas, GitHub a été choisi comme gestionnaire de versions, dont le dépôt du projet se situe ici : [https://github.com/umpri5450/IRock_RICM5_2015 IRock Github].

== Sprints ==
Les tâches et backlog de notre projet sont organisé avec l'outil gratuit Sonic Agile, qui nous permet de construire un tableau Kanban au fur et à mesure.
[[Image:Sonic_backlog_irock.png|800px|thumb|center]]

- Sprint 0 (27/01 -> 02/02)
* Elaboration du cahier des charges.
* Réunion avec les profs de Geotech
* Découvert des cartes Libellium
* Découvert des libraries LoRA

- Sprint 1 (03/02 -> 08/02)
* Tests de communications avec Libellium (Ping Pong)
* Etudier les facteurs de glissement terrain
* Premiere manipulation des weather shields de SparkFun
* Création d'un application qui reveilles les cartes s'il y a du mouvement (6D Position)

- Sprint 2 (09/02 -> 15/02)
* Découverte des cartes STM32 Nucleo
* Tests de communications avec LoRa Fabian (Ping Pong)
* Se familiariser avec les IDEs pour programmer les cartes (Mbed, Keil, STM32 Cube)

- Sprint 3 (16/01 -> 22/02)
* Etudes de la sécurisation des données
* Tester et comprendre les libraries de cryptage/décryptage pour les micro-controllers
* Etudes et codage de LoRA Mote pour communiquer avec Kerlink

- Sprint 4 (23/02 -> 01/03)
* Découverte des cartes LoRA Mbed
* Construction préliminaire des conteneurs des iRocks
* Mise en relation avec les auteurs des libraries Mbed
* Etudes d'une thèse sur la triangularisation des cartes en fonction de RSSI

- Sprint 5 (02/03-> 08/03)
* Conception d'un protocole de communication entre les noeuds
* Ecriture des libraries pour les weather shields de SparkFun
* Etude de STM32 Discovery F3 et F4 surtout les capteurs accéléromètre et magnétomètre.
* Mise en relation avec les auteurs des applications F3 et F4

- Sprint 6 (09/03-> 15/03)
* Mise en place de Grafana et InfluxDB
* Récuperation des données à partir de MQTT
* Terminaison des conteneurs iRocks

- Sprint 7 (16/03->22/03)
* Ecriture des documentations
* Préparation des démos.
* Deboggage

Proj-2014-2015-iRock/Scrum

2015-03-24T21:35:20Z

RICM4-prj14-grp11: /* Sprints */

Encadrant : Didier Donsez, <br>
Etudiants RICM5 :
* PEYRE Flavien (Chef de projet)
* BOEY Lionel (Scrum Master)
* GINOUX Pierre-Henri
* GUO Tianming

== Présentation de l'organisation du projet ==
Ce projet consiste de 4 étudiants de la filière RICM 5, dont un chef de projet et trois développeurs. La durée d'un sprint est fixé à une semaine vu la taille de notre projet et la dynamicité des technologies à évaluer dans le cadre du projet.

A priori, le développement est divisé en 2 parties : la partie embarqué (GUO et BOEY) et la partie visualisation (PEYRE et GINOUX). Pour la partie embarqué, nous nous sommes servi de plusieurs IDE pour programmer les micro-controllers notamment:
* Keil MDK 4 et 5 pour Windows
* Mbed
* Waspmote IDE
* ARM GNU Toolchains plugin sous Eclipse
* STM32 Cube

Au niveau backend(visualisation), nous avons utilisé le langage Python pour manipuler les données reçues et ensuite les stocker sur une base de donnée temporelle (InfluxDB et Grafana).

Dans tous les cas, GitHub a été choisi comme gestionnaire de versions, dont le dépôt du projet se situe ici : [https://github.com/umpri5450/IRock_RICM5_2015 IRock Github].

== Sprints ==
Les tâches et backlog de notre projet sont organisé avec l'outil gratuit Sonic Agile, qui nous permet de construire un tableau Kanban au fur et à mesure.
[[Image:Sonic_backlog_irock.png|800px|thumb|center]]

- Sprint 0 (27/01 -> 02/02)
* Elaboration du cahier des charges.
* Réunion avec les profs de Geotech
* Découvert des cartes Libellium
* Découvert des libraries LoRA

- Sprint 1 (03/02 -> 08/02)
* Tests de communications avec Libellium (Ping Pong)
* Etudier les facteurs de glissement terrain
* Premiere manipulation des weather shields de SparkFun
* Création d'un application qui reveilles les cartes s'il y a du mouvement (6D Position)

- Sprint 2 (09/02 -> 15/02)
* Découverte des cartes STM32 Nucleo
* Tests de communications avec LoRa Fabian (Ping Pong)
* Se familiariser avec les IDEs pour programmer les cartes (Mbed, Keil, STM32 Cube)

- Sprint 3 (16/01 -> 22/02)
* Etudes de la sécurisation des données
* Tester et comprendre les libraries de cryptage/décryptage pour les micro-controllers
* Etudes et codage de LoRA Mote pour communiquer avec Kerlink

- Sprint 4 (23/02 -> 01/03)
* Découverte des cartes LoRA Mbed
* Construction préliminaire des conteneurs des iRocks
* Mise en relation avec les auteurs des libraries Mbed
* Etudes d'une thèse sur la triangularisation des cartes en fonction de RSSI

- Sprint 5 (02/03-> 08/03)
* Conception d'un protocole de communication entre les noeuds
* Ecriture des libraries pour les weather shields de SparkFun
* Etude de STM32 Discovery F3 et F4 surtout les capteurs accéléromètre et magnétomètre.
* Mise en relation avec les auteurs des applications F3 et F4

- Sprint 6 (09/03-> 15/03)
* Mise en place de Grafana et InfluxDB
* Récuperation des données à partir de MQTT

- Sprint 7 (16/03->22/03)
* Préparation des démos.
* Deboggage et écriture des documentations

Proj-2014-2015-iRock/Scrum

2015-03-24T21:24:55Z

RICM4-prj14-grp11: /* Sprints */

Encadrant : Didier Donsez, <br>
Etudiants RICM5 :
* PEYRE Flavien (Chef de projet)
* BOEY Lionel (Scrum Master)
* GINOUX Pierre-Henri
* GUO Tianming

== Présentation de l'organisation du projet ==
Ce projet consiste de 4 étudiants de la filière RICM 5, dont un chef de projet et trois développeurs. La durée d'un sprint est fixé à une semaine vu la taille de notre projet et la dynamicité des technologies à évaluer dans le cadre du projet.

A priori, le développement est divisé en 2 parties : la partie embarqué (GUO et BOEY) et la partie visualisation (PEYRE et GINOUX). Pour la partie embarqué, nous nous sommes servi de plusieurs IDE pour programmer les micro-controllers notamment:
* Keil MDK 4 et 5 pour Windows
* Mbed
* Waspmote IDE
* ARM GNU Toolchains plugin sous Eclipse
* STM32 Cube

Au niveau backend(visualisation), nous avons utilisé le langage Python pour manipuler les données reçues et ensuite les stocker sur une base de donnée temporelle (InfluxDB et Grafana).

Dans tous les cas, GitHub a été choisi comme gestionnaire de versions, dont le dépôt du projet se situe ici : [https://github.com/umpri5450/IRock_RICM5_2015 IRock Github].

== Sprints ==
Les tâches et backlog de notre projet sont organisé avec l'outil gratuit Sonic Agile, qui nous permet de construire un tableau Kanban au fur et à mesure.
[[Image:Sonic_backlog_irock.png|800px|thumb|center]]

- Sprint 0 (27/01 -> 02/02)
* Elaboration du cahier des charges.
* Réunion avec les profs de Geotech
* Découvert des cartes Libellium
* Découvert des libraries LoRA

- Sprint 2 (03/02 -> 08/02)
* Tests de communications avec Libellium (Ping Pong)
* Etudier les facteurs de glissement terrain
* Premiere manipulation des weather shields de SparkFun

- Sprint 3 (09/02 -> 15/02)
* Découverte des cartes STM32 Nucleo
* Tests de communications avec LoRa Fabian (Ping Pong)
* Se familiariser avec les IDEs pour programmer les cartes (Mbed, Keil, STM32 Cube)

- Sprint 4 (16/01 -> 22/02)
* Etudes de la sécurisation des données
* Tester et comprendre les libraries de cryptage/décryptage pour les micro-controllers
* Etudes et codage de LoRA Mote pour communiquer avec Kerlink

- Sprint 5 (23/02 -> 01/03)
* Découverte des cartes LoRA Mbed
*

- Sprint 6 (02/03-> 08/03)
* Reconnaissance et résolution d'équations.
* Amélioration de l'interface existante (ajout de nouvelles fonctionnalités).

- Sprint 7 (09/03-> 15/03)
* Ajout de nouvelles fonctionnalités : affichage d'images en fonction d'un code texte prédéfini.
* Amélioration de l'interface (suite).

- Sprint 8 (16/03->22/03)
* Possibilité d'afficher la courbe associée à une équation.
* Débuggage et finalisation de l'interface.

Proj-2014-2015-iRock/Scrum

2015-03-24T21:08:22Z

RICM4-prj14-grp11: /* Sprints */

File:Sonic backlog irock.png

2015-03-24T21:07:49Z

RICM4-prj14-grp11:

Proj-2014-2015-iRock/Scrum

2015-03-24T21:03:45Z

RICM4-prj14-grp11: /* Présentation de l'organisation du projet */

2015-02-04T19:20:21Z

RICM4-prj14-grp11: /* Le Continous Delivery */

== Le Continous Delivery ==
[[File:Integration.png]]
En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?

Cette problématique répond à l’utilité du concept du Continous Delivery (C.D).
Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour que le code que soit prêt à être déployé directement à l'équipe de production.

[[File:Fonctionnement_Deploiement.png]]

Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet de détectés rapidement les problèmes d’intégration et de les corrigés au fur et à mesure. Aussi grâce au test automatisés mis en place permette de d'identifier les changements problématique. Enfin de connaître et obtenir rapidement la dernière version stable de l'application

Un petit rappel concernant l’intégration continue:
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
* les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications

Pour ce faire, il nécessite de contrôler plusieurs points:
*Contrôler l'intégrité unitaire et fonctionnelle
*S'assurer de l'absence de régressions
*Mesurer la couverture du code
*Surveiller le respect des conventions de codage
*Signaler les erreurs de codage

Un exemple d'outils permettant l’intégration continue est Jenkins, souvent utilisé dans les projets Java développés avec maven, Jenkins est un serveur d’intégration qui s'interface avec des systèmes de gestion de versions tels que CVS, Git et Subversion, et exécute des projets basés sur Apache Ant, Maven...
Jenkins fonctionne avec l'utilisation de Job, on peut configurer des jobs pour que celui-ci par exemple exécute un script à chaque commit ou bien permet de vérifier le bon fonctionnement du code.
Une fois le job configuré, Jenkins permet d'obtenir des courbes de tests, d'analyse statique du code, un historique des productions effectuées. Et le tout de manière claire et simple:

[[File:Hudson-job-main-page.png]]

Un build représente sur Jenkis la creation d'un Job.

Automate.png Maintenant revenant au Continous Delivery, celui-ci est simplement:
'''
Le Continuous Delivery =
'''

== Voir aussi ==
* [[Jenkins (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
* [[Tinderbox (logiciel)|Tinderbox]], serveur d'intégration continue de la [[Mozilla Foundation]]
* [[Apache Continuum]], server de l'[[Apache Software Foundation]]
* [[Team Foundation Server]], serveur [[Microsoft]]
* [[TeamCity]]

=== Liens externes ===

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
* [http://gump.apache.org/ Apache Gump]
* [http://cabie.tigris.org/ CABIE]
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.

== Source Image==

* http://blog.octo.com/devops-de-lintegration-continue-au-deploiement-continu/
* http://igm.univ-mlv.fr/~dr/XPOSE2010/Lecharpentier_Jenkins/images/hudson-job-main-page.png

File:Automate.png

2015-02-04T19:20:08Z

RICM4-prj14-grp11:

Continuous Deliver

2015-02-04T19:05:26Z

RICM4-prj14-grp11: /* Le Continous Delivery */

== Le Continous Delivery ==
[[File:Integration.png]]
En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?

Cette problématique répond à l’utilité du concept du Continous Delivery (C.D).
Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour que le code que soit prêt à être déployé directement à l'équipe de production.

[[File:Fonctionnement_Deploiement.png]]

Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet donc d'avoir plus confiance en son propre code et celui de son équipe, de responsabiliser les intervenants sur la qualité de leur code et surtout pouvoir déployer plus sereinement.

Un petit rappel concernant l’intégration continue:
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
*les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications

Pour ce faire, il nécessite de contrôler plusieurs points:
*Contrôler l'intégrité unitaire et fonctionnelle
*S'assurer de l'absence de régressions
*Mesurer la couverture du code
*Surveiller le respect des conventions de codage
*Signaler les erreurs de codage
*Générer des rapports synthétiques utiles

Un exemple d'outils permettant l’intégration continue est Jenkins, souvent utilisé dans les projets Java développés avec maven, Jenkins est un serveur d’intégration qui s'interface avec des systèmes de gestion de versions tels que CVS, Git et Subversion, et exécute des projets basés sur Apache Ant, Maven...
Jenkins fonctionne avec l'utilisation de Job, on peut configurer des jobs pour que celui-ci par exemple exécute un script à chaque commit ou bien permet de vérifier le bon fonctionnement du code.
Une fois le job configuré, Jenkins permet d'obtenir des courbes de tests, d'analyse statique du code, un historique des productions effectuées. Et le tout de manière claire et simple:

[[File:Hudson-job-main-page.png]]
Un build représente sur Jenkis la creation d'un Job.

Build

== Voir aussi ==
* [[Jenkins (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
* [[Tinderbox (logiciel)|Tinderbox]], serveur d'intégration continue de la [[Mozilla Foundation]]
* [[Apache Continuum]], server de l'[[Apache Software Foundation]]
* [[Team Foundation Server]], serveur [[Microsoft]]
* [[TeamCity]]

=== Liens externes ===

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
* [http://gump.apache.org/ Apache Gump]
* [http://cabie.tigris.org/ CABIE]
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.

== Source Image==

* http://blog.octo.com/devops-de-lintegration-continue-au-deploiement-continu/
* http://igm.univ-mlv.fr/~dr/XPOSE2010/Lecharpentier_Jenkins/images/hudson-job-main-page.png

Continuous Deliver

2015-02-04T19:03:11Z

RICM4-prj14-grp11:

== Le Continous Delivery ==
[[File:Integration.png]]
En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?

Cette problématique répond à l’utilité du concept du Continous Delivery (C.D).
Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour que le code que soit prêt à être déployé directement à l'équipe de production.

[[File:Fonctionnement_Deploiement.png]]

Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet donc d'avoir plus confiance en son propre code et celui de son équipe, de responsabiliser les intervenants sur la qualité de leur code et surtout pouvoir déployer plus sereinement.

Un petit rappel concernant l’intégration continue:
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
*les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications

Pour ce faire, il nécessite de contrôler plusieurs points:
*Contrôler l'intégrité unitaire et fonctionnelle
*S'assurer de l'absence de régressions
*Mesurer la couverture du code
*Surveiller le respect des conventions de codage
*Signaler les erreurs de codage
*Générer des rapports synthétiques utiles

Un exemple d'outils permettant l’intégration continue est Jenkins, souvent utilisé dans les projets Java développés avec maven, Jenkins est un serveur d’intégration qui s'interface avec des systèmes de gestion de versions tels que CVS, Git et Subversion, et exécute des projets basés sur Apache Ant, Maven...
Jenkins fonctionne avec l'utilisation de Job, on peut configurer des jobs pour que celui-ci par exemple exécute un script à chaque commit ou bien permet de vérifier le bon fonctionnement du code.
Une fois le job configuré, Jenkins permet d'obtenir des courbes de tests, d'analyse statique du code, un historique des productions effectuées. Et le tout de manière claire et simple:

[[File:Hudson-job-main-page.png]]

Build

== Voir aussi ==
* [[Jenkins (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
* [[Tinderbox (logiciel)|Tinderbox]], serveur d'intégration continue de la [[Mozilla Foundation]]
* [[Apache Continuum]], server de l'[[Apache Software Foundation]]
* [[Team Foundation Server]], serveur [[Microsoft]]
* [[TeamCity]]

=== Liens externes ===

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
* [http://gump.apache.org/ Apache Gump]
* [http://cabie.tigris.org/ CABIE]
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.

== Source Image==

* http://blog.octo.com/devops-de-lintegration-continue-au-deploiement-continu/
* http://igm.univ-mlv.fr/~dr/XPOSE2010/Lecharpentier_Jenkins/images/hudson-job-main-page.png

Continuous Deliver

2015-02-04T19:01:52Z

RICM4-prj14-grp11:

== Le Continous Delivery ==
En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?

Cette problématique répond à l’utilité du concept du Continous Delivery (C.D).
Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour que le code que soit prêt à être déployé directement à l'équipe de production.

[[File:Fonctionnement_Deploiement.png]]

Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet donc d'avoir plus confiance en son propre code et celui de son équipe, de responsabiliser les intervenants sur la qualité de leur code et surtout pouvoir déployer plus sereinement.

Un petit rappel concernant l’intégration continue:
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
*les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications

Pour ce faire, il nécessite de contrôler plusieurs points:
*Contrôler l'intégrité unitaire et fonctionnelle
*S'assurer de l'absence de régressions
*Mesurer la couverture du code
*Surveiller le respect des conventions de codage
*Signaler les erreurs de codage
*Générer des rapports synthétiques utiles

Un exemple d'outils permettant l’intégration continue est Jenkins, souvent utilisé dans les projets Java développés avec maven, Jenkins est un serveur d’intégration qui s'interface avec des systèmes de gestion de versions tels que CVS, Git et Subversion, et exécute des projets basés sur Apache Ant, Maven...
Jenkins fonctionne avec l'utilisation de Job, on peut configurer des jobs pour que celui-ci par exemple exécute un script à chaque commit ou bien permet de vérifier le bon fonctionnement du code.
Une fois le job configuré, Jenkins permet d'obtenir des courbes de tests, d'analyse statique du code, un historique des productions effectuées. Et le tout de manière claire et simple:

[[File:Hudson-job-main-page.png]]

[[File:Integration.png]]

== Voir aussi ==
* [[Jenkins (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
* [[Tinderbox (logiciel)|Tinderbox]], serveur d'intégration continue de la [[Mozilla Foundation]]
* [[Apache Continuum]], server de l'[[Apache Software Foundation]]
* [[Team Foundation Server]], serveur [[Microsoft]]
* [[TeamCity]]

=== Liens externes ===

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
* [http://gump.apache.org/ Apache Gump]
* [http://cabie.tigris.org/ CABIE]
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.

== Source Image==

* http://blog.octo.com/devops-de-lintegration-continue-au-deploiement-continu/
* http://igm.univ-mlv.fr/~dr/XPOSE2010/Lecharpentier_Jenkins/images/hudson-job-main-page.png

2015-02-04T17:32:09Z

RICM4-prj14-grp11: /* Le Continous Delivery */

== Le Continous Delivery ==
En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?

Cette problématique répond à l’utilité du concept du Continous Delivery (C.D).
Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour le code que soit prêt à être déployé directement à l'équipe de production.

[[File:Fonctionnement_Deploiement.png]]

Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet donc d'avoir plus confiance en son propre code et celui de son équipe, de responsabiliser les intervenants sur la qualité de leur code et surtout pouvoir déployer plus sereinement.

Un petit rappel concernant l’intégration continue:
*Le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
*les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications

Pour ce faire, il nécessite de contrôler plusieurs points:
*Contrôler l'intégrité unitaire et fonctionnelle
*S'assurer de l'absence de régressions
*Mesurer la couverture du code
*Surveiller le respect des conventions de codage
*Signaler les erreurs de codage
*Générer des rapports synthétiques utiles

[[File:Jenkins-global.png]]

[[File:Integration.png]]

== Voir aussi ==
* [[Jenkins (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
* [[Tinderbox (logiciel)|Tinderbox]], serveur d'intégration continue de la [[Mozilla Foundation]]
* [[Apache Continuum]], server de l'[[Apache Software Foundation]]
* [[Team Foundation Server]], serveur [[Microsoft]]
* [[TeamCity]]

=== Liens externes ===

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
* [http://gump.apache.org/ Apache Gump]
* [http://cabie.tigris.org/ CABIE]
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.

== Source Image==

* http://blog.octo.com/devops-de-lintegration-continue-au-deploiement-continu/

File:Jenkins-global.png

2015-02-04T17:27:20Z

RICM4-prj14-grp11:

Continuous Deliver

2015-02-04T17:20:05Z

2015-02-04T16:21:47Z

RICM4-prj14-grp11: /* L'intégration continue */

Avant de parler du continous delivery, il est important dans un premier temps de rappeler l’intégration continue :

== Le Continuous Delivery : Qu’est ce que c’est ? ==

Il est déjà opportun de différencier deux notions : le Continuous Deployment du Continuous Delivery (Déploiement vs Livraison).

Le déploiement continue consiste à mettre en production à chaque changement, quelque soit le changement. La livraison continue, quand à elle, s’attache à raccourcir le cycle d’obtention de la valeur, en s’intéressant à l’intégralité de la chaîne (pipeline) permettant de créer cette valeur.

Afin de délivrer cette valeur, il est alors question d’automatiser les différentes étapes de son pipeline de façon à pouvoir déployer en production à tout moment. Car en premier lieu, il est surtout question d’être capable de déployer dès qu’on le souhaite, rapidement, souvent et ceci avec un risque minimal lié à la procédure (erreur humaine, problème lié à l’environnement, problème de package…).

[[File:rad1.jpg]]

Ainsi les grands acteurs du web (facebook, google, instagram, Netflix…) déploient en production plusieurs fois par jour, ce qui leur donnent une grande capacité de réaction et une optimisation du Time To Market.

A noter que de façon à pouvoir mettre en place le Continuous Delivery, il est indispensable d’assurer une grande qualité du code source produit et d’avoir confiance en la qualité de ce code source (et donc d’avoir des métriques) . Et ceci, par la mise en place au sein de son projet des pratiques telles que les tests unitaires, le Behaviour Driven Development, l’intégration continue…

Pour permettre le Continuous Delivery, vous devez ainsi passer un certain nombre d’étapes comme une course d’obstacle. Ces obstacles peuvent être soit de type organisationnels, soit de type techniques. Certains de ces obstacles pourront être passés grâce à des méthodes bien connues, ou que l’on adaptera pour répondre précisément aux problématiques rencontrées. Pour d’autres, il sera nécessaire de mettre en place des outils spécifiques ou d’adopter des infrastructures plus moderne pouvant répondre à ces problématiques.

== Le Continuous Delivery : Pourquoi ? ==

“Quand ça fait mal, il faut le faire souvent (if it hurts, do it more often)”

Il est effectivement important de souligner que la construction du livrable et son déploiement, même quand cela est fait automatiquement, sont des moments chargés “d’émotions” et lourd de sens. Il est même courant d’espacer au maximum ces livraisons afin d’atténuer la souffrance. On est alors en droit de se demander : A-t-on vraiment besoin de souffrir ? Comment gérer ces prises de risque afin de les supprimer ?

Livrer aussi souvent que possible, livrer du matin au soir, que chaque commit soit immédiatement mis en production est le but ultime. Plus vous livrez, plus vos packages seront petits et les risques amoindris. Plus vous livrez et plus votre rigueur sera grande, car il n’est plus question de réaliser certaines tâches “plus tard” ou de laisser des choses à faire qu’on oublie parfois et qui rendent les phases de livraisons plus complexes que prévues.

Alors vous vous dites peut être oui, mais… Si je n’ai pas envie de livrer cette fonctionnalité ?
Ma réponse : Vous n’avez pas envie de livrer cette fonctionnalité ou vous n’avez pas envie de l’activer ?

Une des approches est de découpler la livraison de l’activation. On parle du pattern toggle feature pattern. La fonctionnalité est présente dans le logiciel qui est mis en production mais elle n’est pas disponible, ni utilisable. L’activation de la fonctionnalité est rendu paramétrable dans la configuration du logiciel. Bien évidemment cette approche a aussi ses défauts et donne lieu à du refactoring régulier afin d’enlever le code conditionnel une fois que la fonctionnalité est validée et utilisée. Le toggle feature permet aussi d’être au plus près du besoin métier : activer une feature à la demande. Cela permet par exemple de gérer au niveau du produit une activation de service plutôt que de porter cette complexité au niveau d’une organisation / coordination d’équipe et des plannings éventuels. Aussi vite que ce besoin n’est plus exprimé par le métier, le code d’activation/désactivation est supprimé, permettant de rester en adéquation avec le besoin fonctionnel.

== Le continuous delivery : Comment ? ==

===Etat des lieux et définition du pipeline de votre projet===

Une première étape lorsque vous voulez mettre en place le Continuous Delivery dans votre projet/entreprise est de faire un état des lieux de votre Pipeline (constitué par toutes les étapes à partir du besoin jusqu’à la mise en production) et d’estimer le temps passé lors de chaque étape. Il n’est pas question de faire un bing-bang : il faut faire évoluer étape par étape adressant les goulots d’étranglement les uns après les autres et savoir s’adapter au contexte de votre projet/entreprise.

[[File:Pipeline.png]]

Une fois que vous avez identifié les différentes briques de votre Pipeline, vous pourrez identifier quelles sont les étapes qui prennent le plus de temps, celles qui sont les plus douloureuses ou celles qui sont le plus obscures. Posez vous la question de ce qui est possible d’améliorer. Pour cela, identifiez les pratiques automatisées et les pratiques manuelles ainsi que ce qui empêche l’automatisation. Quelles sont les étapes qui vous demande le plus de temps. Quelles sont les étapes qui sont entièrement sous votre contrôle et celles qui sont dépendantes de décisions ou d’actions externes à votre projet.

De cet état des lieux, vous pourrez investiguer sur les causes de vos maux afin de les adresser. Vous vous rendrez probablement compte que certaines étapes sont très consommatrices de temps (en charge ou en délais) sans forcément donner un retour sur investissement.

===Automate all the things – Il faut tout automatiser===
Si vous vous posez la question de savoir qu’elle démarche appliquer la réponse est simple :

[[File:Automation.png]]

En effet, le continuous delivery prends tout son sens lorsque toutes les étapes du pipeline sont entièrement automatisées. Ainsi, lorsque toutes les étapes sont automatisées, le temps entre la première étape et la dernière étape peut être connu et garanti ( on n’est pas obligé d’attendre qu’une personne bien précise soit disponible pour pouvoir faire la livraison, chaque étape est rejouable à loisir et son temps d’exécution est mesuré et historisé).
Il faut par ailleurs garder à l’esprit que, bien que toutes les étapes soient automatisées (c’est-à-dire qu’aucune intervention manuelle n’est nécessaire pour réaliser une étape du pipeline), il peut arriver que le déclenchement d’une ou plusieurs étapes soit faite manuellement du fait de contraintes fortes externe au projet ( validation par une entité externe à l’entreprise par exemple). Même si c’est le genre de cas qu’on cherchera particulièrement à éviter.

Les commandements de l’automatisation
Tu automatiseras tout, absolument tout :

*Tu n’installeras pas manuellement tes dépendances ;
*Tu automatiseras ta build ;
*Tu automatiseras tes tests ;
*Tu ne configureras pas à la main;
*Tu ne créeras plus de machine à la main ;
*Tu n’interviendras pas pour livrer ;
*Des métriques tu auras, tes machines tu monitoreras ;

Vous l’aurez compris, pour la mise en place du Continuous Delivery, il faut que tout soit automatisé et répétable. Ainsi, il faut adresser l’environnement de production (sa construction) dès le départ. De fait, dès la mise en place de l’intégration continue, il faut faire en sorte que l’environnement dans lequel se font les différents tests (unitaires, intégration, performance,…) soient fait dans un environnement identique, sinon le plus semblable possible à l’environnement de production, de façon à se rendre compte le plus tôt possible des problèmes potentiels liés à l’environnement.

Un pattern répandu qui peut être mis en place est l’Infrastructure As Code où l’environnement est mis en place grâce à des scripts de configuration. Pour cela on utilisera des outils permettant de simplifier ce travail (Puppet, Chef, Vagrant, Docker, …).

Donc plus rien ne doit rester une tâche manuelle, et tous les artefacts permettant la mise en production doivent ainsi être archivés dans le contrôleur de code source : les scripts de mise à jour de la base de donnée, la configuration des environnements, les scripts de déploiement, …
Le Continuous Delivery, c’est aussi un rythme

== Quel rythme pour le continuous delivery ? Quel changement implique-t-il ? ==

Une des interrogations des plus intéressantes qui nous pousse à avoir cette démarche, est de nous interroger, sur la valeur à donner à des fonctionnalités développées mais non encore mise en production. La réponse, brutale et non moins réalise, est : aucune.

Un des travers que nous pouvons rencontrer encore maintenant sur les projets, est de voir les fonctionnalités s’accumuler.

Toute cette perte de temps est causée parfois par le focus mis sur le développement de nouvelles fonctionnalités sans se soucier de leur livraison… Cette perte de temps est un travers fréquent lors de l’utilisation de la méthode Scrum où la vélocité est calculé par la capacité de l’équipe à produire du code et non pas de la valeur.

Nous pourrions proposer un nouveau principe : rendre votre produit déployable plutôt que livrer de nouvelle fonctionnalités puisque toute fonctionnalité non livrée n’amène pas de valeur.

== Voir aussi ==
* [[Jenkins (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
* [[Tinderbox (logiciel)|Tinderbox]], serveur d'intégration continue de la [[Mozilla Foundation]]
* [[Apache Continuum]], server de l'[[Apache Software Foundation]]
* [[Team Foundation Server]], serveur [[Microsoft]]
* [[TeamCity]]

=== Liens externes ===

* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
* [http://gump.apache.org/ Apache Gump]
* [http://cabie.tigris.org/ CABIE]
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.