Application Security Resources

Sub Text of Application Security Resources

L’intégration continue dans le développement Agile

February 26, 2014

Tiny Url for this post: http://tinyurl.com/pw6o66u

Introduction

Les processus de développement logiciel modernes ont adopté une approche incrémentale et itérative plutôt que l’approche traditionnelle qui est linéaire et n’est pas souple par rapport aux modifications.

Depuis de nombreuses années, les processus Agile ont été largement acceptés sur la scène commerciale. Agile compose avec des exigences volatiles et utilise un certain nombre de méthodes telles que la planification simple, l’itération courte, la version antérieure et des retours d’expérience réguliers. Ces techniques permettent à la méthodologie agile de livrer le produit en un court laps de temps si l’on compare aux modèles traditionnels.

L’un des principes clés du processus agile est de tout faire par petites étapes, mais en continu. Il s’agit de développer de petites itérations, d’estimer de petites quantité de travail et de remaniements par petites étapes. Comme Martin Fowler le définit, la fréquence réduit la difficulté, c’est une spécialisation de « diviser pour régner ».

Dans la méthodologie agile, chaque aspect du développement est sans cesse revisité tout au long du cycle de vie. Les équipes Agile sont très utiles pour la réorientation vers une stratégie de conception et de développement flexible et globale.

L’enchaînement des processus pour les équipes est indiqué ci-dessous. Ici, la planification et les équipes d’architecture définissent les capacités de développement du système. La période pré-planification comprend la planification technique, l’analyse des besoins, les exigences d’articulation et la création du système d’architecture. Les entrées de cette étape pré-planification comprennent les capacités nécessaires du client et la sortie résultante est une vision, un plan à suivre et une architecture. Durant la phase de pré-planification, l’équipe en charge de la planification définit le champ et les résultats du projet, et l’équipe d’architecture établit la vision, l’architecture et une liste des fonctionnalités souhaitées du produit (le backlog produit). Quelques éléments de l’architecture peuvent être identifiés pour analyse et élaboration ultérieures dans le cycle de mise en œuvre.

Le résultat de la phase de pré-planification s’écoule dans la première itération. L’équipe de l’architecture actualise la liste des capacités souhaitées et prépare les matériaux pour l’équipe d’implémentation. Ces matériaux peuvent inclure des exigences, des capacités et l’expérience d’utilisateurs. L’équipe de l’architecture peut également travailler avec l’équipe d’implémentation pour maintenir l’architecture alors que la conception détaillée évolue et assister les développeurs pour aligner le produit aux exigences proposées. L’équipe d’intégration et de test met en œuvre l’environnement de test. Dans les itérations suivantes, le produit fini provenant de toutes les équipes sera testé par l’équipe d’intégration et de test pour vérifier les exigences en interne et avec les clients.

Si des modifications de l’architecture sont nécessaires, alors l’équipe de l’architecture la révise en vue de pouvoir prendre en charge le développement des capacités à venir. Cela peut inclure la révision de l’architecture, des études commerciales et la révision de la base de données. Ici, l’objectif est de fournir une architecture de systèmes modulaire qui résiste au changement.Toutes les itérations se poursuivent jusqu’à la finalisation de la version. La version est exposée aux parties intéressées et à l’équipe de planification pour examen et approbation. Les modifications demandées sont alors prévues dans la prochaine version. Lors de la démonstration de la version finale, les développeurs vérifient si le logiciel final répond à toutes les exigences.


Nécessité de l’intégration continue dans le développement agile

L’intégration continue (IC) est une pratique répandue dans la méthodologie Agile. Les équipes d’IC doivent maintenir le système entièrement intégré à tout moment. L’intégration peut se produire plusieurs fois par jour. Ici, le point important est que l’IC détecte suffisamment de bogues pour valoir le coût. L’IC minimise le temps passé à la recherche de bogues et identifie très tôt les problèmes de compatibilité.

Les entreprises qui ont mis en œuvre des processus agiles ont déjà observé de grandes améliorations, aussi bien en coût et stabilité qu’au niveau de l’utilité du logiciel. L’intégration continue met en évidence les changements de culture nécessaires pour devenir une entreprise agile. La clé pour construire une culture qui prend en compte l’IC est de faire en sorte que cela fonctionne dès la première fois.

L’intégration continue nécessite un certain effort. Si vous êtes engagé dans Agile, alors il ne s’agit pas d’un luxe mais une nécessité. L’effort engagé dans l’IC se reflétera dans la qualité du code, la réactivité de l’équipe et dans la confiance en un travail bien fait. Mais ne vous laissez pas méprendre par le mot « continue ». L’intégration se produisant seulement à certains intervalles ou lorsque déclenchée par un événement, L’IC n’est en fait pas continue. L’intégration continue signifie qu’elle se produit toujours régulièrement.

L’IC est associée aux concepts d’élimination des déchets et de rétroaction rapide. Le déchet est ici considéré comme quelque chose qui n’ajoute aucune valeur pour les clients.

Il existe quelques différentes méthodes pour éliminer les déchets. Une méthode efficace consiste à identifier et traiter les anti-modèles dans le processus de réalisation de logiciels. Les pratiques inefficaces ou contre-productives sont connues comme anti-modèle (antipatterns), elles produisent des conséquences indésirables. Explorons deux d’entre elles :

Branches non optimales et fusion

L’activité de développement en parallèle (notamment en cas de grands projets) conduit à la création de nombreuses branches. La fusion des branches peut devenir un processus pénible. Lorsque les branches deviennent plus distinctes, la fusion devient encore plus complexe. Nous pouvons atténuer ce problème en testant et en intégrant plus souvent, et également par l’utilisation du serveur d’IC pour générer automatiquement le logiciel lors de l’intégration.

Cycles de tests longs

Lorsque l’équipe de développement passe le travail à l’équipe d’assurance qualité, parfois un manque d’automatisation peut conduire à des cycles de tests longs. Les tests manuels et l’aide de tableurs pour documenter les résultats peuvent influer sur la sortie de la version par un impact sur la qualité du produit.

Pour éviter ce problème, un framework, infrastructure d’applications de tests, devrait être intégré de sorte que le processus de génération comprenne une variété de tests tels que les tests unitaires, d’intégration, de fonctionnalité et non fonctionnalité, et les tests d’acceptation, avec un mécanisme de rétroaction intégré. Le cadre d’applications doit également inclure des seuils pour les tests. À titre d’exemple, dans le cas de tests unitaires, il pourrait y avoir un minimum de 75 à 80 % de couverture. Si cette valeur descend sous 75 %, alors elle doit être améliorée en indiquant la mouture (le build) comme « mauvaise », non fonctionnelle.

Comment l’intégration continue minimise-t-elle la friction pour un projet ?

La friction est clairement visible dans un processus plus itératif. Vous pouvez faire usage de certains principes de génie logiciel qui permettent les processus itératifs et “lubrifient les frictions”.  Un de ces principes est l’intégration continue. La pratique de l’IC signifie produire des moutures intégrées très fréquemment, habituellement à chaque apport au contrôle du code source.

Vous devez utiliser un dépôt référentiel de contrôle de version pour mettre en œuvre l’IC. L’objectif d’un référentiel est de gérer les changements du code source et d’autres tels que la documentation. Le référentiel vous permet de revenir en arrière dans le temps et d’accéder à différentes versions du code.


Lorsque vous appliquez des changements au dépôt référentiel du code source, le serveur d’IC produit une mouture du logiciel, build d’intégration. Vous pouvez également configurer le serveur pour vérifier les changements toutes les quelques minutes. Le serveur va récupérer tous les fichiers et lancer un script de compilation de la mouture. Les serveurs d’IC peuvent également être paramétrés pour compiler les moutures à une fréquence régulière.

Le serveur d’IC génère une rétroaction, à savoir qu’il envoie la mouture et les résultats des tests à un système de rétroaction, toutes les parties intéressées peuvent ainsi connaître l’état de la mouture. Le serveur continue à interroger les modifications dans le référentiel.

Les types exacts de moutures dont vous avez besoin peuvent dépendre de votre produit et de l’environnement. Certains des différents types de moutures que vous pouvez produire avec l’IC sont indiqués dans le tableau ci-dessous.

Lors de l’introduction de l’IC et des diverses moutures, les équipes de projet peuvent résister à certains de ces changements. Nous allons traiter de la façon de surmonter ces aprioris.


Comment surmonter la résistance initiale ?

Certains aprioris importants sont :

L’IC signifie plus de maintenance

Il s’agit en fait d’une perception erronée. La gestion d’un système d’IC robuste est meilleure que la gestion des processus manuels. Après la mise en place du système et l’intégration complète d’un projet, l’équipe peut gagner du temps car il est plus facile de tester l’application et corriger les bogues. La maintenance prend moins d’une heure par semaine avec le processus d’IC.

Trop de modifications, trop rapidement

Dans le cas de projets existants, certaines équipes estiment qu’il y a trop de processus à modifier afin de parvenir à une intégration continue. Mais nous n’avons pas besoin de tout mettre en œuvre à la fois. Une approche progressive est la plus efficace. Nous pouvons commencer avec simplement une mouture par jour et ajouter des tests unitaires. Au fur et à mesure que l’équipe se familiarise avec les résultats, vous pouvez augmenter légèrement la fréquence des moutures compilées par jour.

Moutures non fonctionnelles

Cela peut se produire lorsque les développeurs ne génèrent pas de mouture personnelle avant d’envoyer leur code. Il se peut que quelques tests d’un développeur aient échoués ou qu’il ait oublié de vérifier un fichier. En raison de la fréquence des modifications, une réponse rapide est essentielle avec l’utilisation de l’IC.

L’IC engendre des coûts supplémentaires en matériel et logiciels

Une machine d’intégration autonome est nécessaire pour utiliser efficacement l’intégration continue. Cela est généralement peu coûteux par rapport aux coûts de la recherche de problèmes dans le développement ultérieur.

Il revient aux développeurs d’effectuer ces activités

Il semble que l’IC soit une duplication des activités de développement. Oui, les développeurs ont à accomplir certaines de ces activités et ils ont besoin, pour le faire de manière fiable et efficace, d’un environnement séparé. Mais un système automatisé peut améliorer l’efficacité et la fréquence de ces activités et il garantit également qu’elles sont effectuées dans un environnement sain. Cela permet aux développeurs de se concentrer sur les questions importantes pour le commerce de l’application.

Le projet est trop avancé pour ajouter l’IC

Il est toujours facile de placer un nouveau projet sous un processus d’IC. Mais la plupart du travail que nous effectuons est de maintenir les projets existants. Un projet existant peut ne pas avoir de tests unitaires, mais vous pouvez utiliser le contrôle du code source et devez produire des moutures. Vous pouvez obtenir des avantages de l’IC, peu importe à quelle étape en est votre projet.

Suivre un bon processus d’IC implique certainement plus d’étapes et une compréhension détaillée du processus. Avant de vérifier leurs propres modifications, tous les développeurs doivent être au fait des modifications nécessaires pour l’intégration avec le reste du système. Cela signifie qu’ils doivent avoir une meilleure compréhension du fonctionnement général du système. Cette compréhension a certainement de nombreux autres avantages pour l’équipe.

Pour effectuer le travail d’intégration, les développeurs doivent parfois également être en mesure d’effectuer des modifications dans le code des autres. Si les membres de l’équipe ont un haut degré d’appropriation du code, alors la transition vers l’IC peut être difficile et prendre du temps. Si tout le monde est prêt et en mesure de suivre le processus, il va rapidement être remarqué combien le processus d’intégration devient plus facile pour tout le monde et l’économie du temps passé à attendre que quelqu’un d’autre s’occupe des questions d’intégration.

Choisir le bon serveur d’intégration continue

Le serveur d’IC vérifie s’il y a eu une actualisation sur le système de contrôle de code source. Si c’est le cas, il récupère le code et commence le processus de compilation de la mouture. L’ensemble du processus s’effectue dans une boucle infinie. Chaque fois que le développeur envoie une modification dans le référentiel du code source, elle est intégrée tôt ou tard.


Choisir le serveur d’IC adéquat n’est pas une tâche facile. Vous devez faire face à la fois aux aspects logiciels et matériels. Sur le plan du matériel, vous devez déterminer si vous disposez d’une machine physique distincte sur laquelle installer votre serveur d’IC. Est-ce une vieille machine posée dans un coin ?(ou) Est-ce un serveur dédié complet avec 99,9 % de disponibilité (ou) Si vous n’avez pas de machine physique, pouvez-vous installer un serveur virtuel afin que chaque membre de l’équipe puisse y accéder ?

Mais il est fortement recommandé de dédier une machine séparée pour le serveur d’IC. Parce qu’un processus d’IC parfaitement créé devrait avoir aussi peu de dépendances que possible.

Certains serveurs d’IC peuvent avoir besoin d’autres services afin d’étendre leur fonctionnalité. Vous n’êtes pas censé installer des applications supplémentaires sur le serveur produisant les moutures, à moins qu’elles ne prennent part au processus de génération.

L’autre raison d’utiliser une machine dédiée pour compiler les moutures en continu est que vous pouvez la conserver à l’écart de toutes les modifications de configuration que vous effectuez normalement. Vous n’avez donc plus de doutes concernant le logiciel installé.

Pour ce qui est du matériel, les meilleures performances possibles sont toujours préférables. La production de la mouture doit être la plus rapide possible. Après avoir introduit une nouvelle fonctionnalité dans le système de contrôle du code source, chaque membre de l’équipe doit attendre que la mouture d’IC se termine et vérifier pour s’assurer que tout a fonctionné comme prévu. Il n’est pas nécessaire que les développeurs soient écartés de leur tâche trop longtemps. Dans les faits, un processeur rapide et un disque dur rapide sont toujours moins coûteux que le temps d’un développeur.

Lorsque vous avez une machine d’intégration dédiée prête à héberger un serveur d’IC, vous pouvez déterminer quel serveur vous conviendra. De nombreux serveurs d’IC sont disponibles et si vous avez besoin de choisir judicieusement, considérez ces cinq points :

  • Quelle somme souhaitez-vous dépenser ?
  • Prend-il en charge d’autres outils dont vous avez besoin ?
  • Est-il facile à utiliser ?
  • Quelle est la qualité de la documentation et de l’assistance ?
  • Ses possibilités sont-elles supérieures à vos besoins ? – Pas simplement actuellement mais également pour le futur.

Les meilleures pratiques

Les développeurs doivent modifier leurs habitudes de développement de logiciels pour que l’IC fonctionne efficacement. Ils doivent soumettre du code plus fréquemment et écrire des scripts de compilation automatisée comportant des tests qui réussissent 100 % du temps.

Voici quelques-unes des meilleures pratiques :

  • Soumettre du code fréquemment
  • Ne pas soumettre de code défectueux
  • Réparer les moutures non fonctionnelles
  • Tests du développeur automatisés
  • Tous les tests et contrôles doivent réussir
  • Maintenir des moutures personnelles
  • Suivi des progressions
  • S’en tenir à ce qui fonctionne

Soumettre du code fréquemment

Afin de bénéficier des avantages de l’IC, les développeurs doivent soumettre du code fréquemment. Attendre plus d’un jour pour envoyer le code sur le dépôt référentiel peut rallonger le processus d’intégration et empêche l’équipe de pouvoir utiliser les dernières modifications.

N’essayez pas de modifier plusieurs composants à la fois. Choisissez une petite tâche, écrivez les tests et le code, exécutez vos tests, puis soumettez votre code au référentiel.

Vous pouvez également éviter que tous soumettent leur code en même temps. Car il y aura plus d’erreurs de compilation à traiter en raison des conflits entre les modifications.

Ne pas soumettre de code défectueux

Un script de compilation bien pensé peut compiler et tester le code d’une manière reproductible. La compilation d’une mouture personnelle avant l’envoi du code sur le référentiel peut être considérée comme faisant partie de la stratégie de développement de logiciel.

Réparer les moutures non fonctionnelles

Un build défectueux empêche la production d’une mouture fonctionnelle. Il peut s’agir d’une erreur de compilation, d’un échec d’inspection, d’un problème de base de données ou échec de déploiement. Ces questions doivent être traitées immédiatement en fonctionnant dans un environnement d’IC .La culture du projet doit révéler que la résolution des problèmes engendrant un échec est une priorité absolue. Ainsi, chaque membre de l’équipe, et pas seulement quelques-uns, peut revenir à ce qu’il a fait.

Tests du développeur automatisés

La génération d’une mouture doit être entièrement automatisée. Les tests doivent être automatisés en vue d’effectuer des tests pour un système d’IC. Écrire vos tests dans les cadres d’applications xUnit (tels que NUnit ou JUnit) exécutera ces tests de façon automatisée.

Tous les tests et contrôles doivent réussir

Les tests automatisés sont aussi importants que la compilation. L’équipe peut utiliser un ensemble de règles générales de codage et de normes de conception par lequel tout le code doit passer. Certaines inspections avancées qui ne font pas échouer le processus peuvent être ajoutées, mais elles déterminent des parties du code qui doivent être étudiées avec attention.

Maintenir des moutures personnelles

Pour éviter les moutures défectueuses, les développeurs doivent émuler une version d’intégration dans l’EDI de leur poste de travail local après avoir terminé leurs tests unitaires. Cette mouture vous permet d’intégrer la nouvelle version fonctionnelle du programme à celle des autres membres de l’équipe, en recueillant les changements depuis le référentiel et en produisant la version localement avec les modifications récentes.

Suivi des progressions

La cohérence de votre démarche d’IC vous permet d’identifier et de gérer les tendances tout au long du cycle de développement. Avec un historique des moutures des versions précédentes sur le tableau de bord du projet, les responsables et les développeurs du projet peuvent suivre le ratio de réussite ou d’échec des moutures et identifier les problèmes de qualité. Les tendances des rapports de couverture et les outils d’analyse peuvent aider les développeurs à gérer la croissance de manière efficace.

S’en tenir à ce qui fonctionne

Les équipes de projet disposant d’une bonne stratégie d’IC n’ont pas besoin de modifier leur processus après leur premier produit livrable en production. Les efforts de maintenance de l’application qui sont de courte durée avec un objectif limité s’intégreront bien dans les approches existantes. Lorsque les équipes se concentrent sur la gestion des modifications au cours de l’ensemble du cycle de développement, les demandes de modifications sont partie intégrante de leur travail.

Conclusion

Par conséquent, l’intégration continue traite avec de nombreux éléments, dont un référentiel de contrôle de code source, un système automatisé de génération des moutures de version, des tests, et un serveur d’IC. Lorsque le code source est modifié dans le dépôt de référence, le serveur d’IC détecte automatiquement les modifications, exécute tous les tests et compile le produit final, l’objectif étant de détecter les problèmes le plus tôt possible dans le processus.

L’IC s’appuie davantage sur les personnes que sur les outils. Pour être efficaces, les développeurs doivent vérifier fréquemment les modifications de leur code auprès du référentiel de code source, s’assurer que les tests sont effectués et intervenir immédiatement pour remédier aux échecs de tests lorsque c’est le cas.

Ces tests en échec étant clairement visibles et la rétroaction immédiate, le serveur d’IC agit comme un membre supplémentaire de l’équipe lors de réunions debout quotidiennes, pointant les problèmes à régler et focalisant l’équipe sur la qualité. Un serveur d’IC peut également conserver les moutures antérieures et facilite le retour à une version précédente.

Remarque : l’intégration continue n’est pas destinée à supprimer les bogues logiciels, mais elle améliore leur détection et évite que les membres de l’équipe ne se dirigent dans la mauvaise direction.

This post is also available in: Anglais

Learn more about Seeker

More Livres Blancs