La livraison continue facilite la vie d'un produit en évolution, du développement jusqu'à la mise en production. L'intégration continue (IC) joue un rôle important dans ce processus et définit le cycle de vie du logiciel, résidant au début du processus de livraison continue.
Il y a une foule d'informations dans les livres et sur Internet décrivant les processus d'IC. Cependant, avec un nombre important d'outils d'IC différents disponibles, il y a très peu d'information sur les tâches de construction, lesquelles compilent et testent le code, et qui constituent donc un élément central dans le processus de l'IC.
Un processus type d'IC est le suivant : le développeur construit et teste le code manuellement sur sa machine. Il commit ensuite ses modifications sur un système de gestion de version. Par la suite, un moteur de production exécute des tâches qui compilent et testent le code. L'artefact construit est ensuite transféré sur un dépôt central prêt à être déployé et testé.
Par conséquent, c'est le rôle des tâches dans l'outil d'IC d'organiser les modifications continues du code, d'exécuter les tests et de gérer la logistique de la mise à disposition de l'artefact pour le déploiement.
Le nombre de tâches dans un moteur de production peut aller de quelques-unes à plusieurs milliers, effectuant toutes diverses actions. Heureusement, il y a un moyen d'organiser toutes ces tâches d'une façon plus efficiente.
Création Automatique des Tâches de Construction
Ainsi, pourquoi devrions-nous mettre en place un système permettant d'automatiser la création d'autres tâches ?
Les manuels utilisateurs des moteurs de production décrivent comment créer une tâche de construction, mais ils n'expliquent pas souvent comment les gérer en détail, bien que la fonctionnalité soit disponible dans l'outil.
Normalement, le développeur sait comment son application est construite et par conséquent prend l'entière responsabilité de la création et configuration de la tâche de construction. Cependant, ce processus a quelques désavantages :
- Contraintes architecturales du logiciel : les applications sont susceptibles d'être construites différemment les unes des autres, en fonction de leur architecture. Un développeur peut interpréter la façon dont une application est construite différemment d'un autre développeur, et donc la configuration de construction différera légèrement d'une tâche à une autre. Par conséquent, un grand nombre de tâches deviennent difficiles à maintenir si elles sont toutes configurées différemment.
- Facteur humain : créer manuellement une tâche introduit le risque de faire des erreurs, notamment si une nouvelle tâche est créée en copiant une tâche existante et en la modifiant.
- Contrôle de l'historique des tâches : généralement, aucune trace n'est gardée de la configuration d'une tâche pour chaque construction, c'est-à-dire que si la configuration est changée, cela pourrait casser les constructions précédentes.
Donc en considérant les points ci-dessus, si les développeurs sont "abandonnés à leur sort" pour créer les tâches de construction sans une méthode consistante pour créer une tâche, nous allons arriver à un système d'IC mal maintenu et à un casse-tête à gérer. Ceci est contraire au principe même de comment un système d'IC devrait être mis en place, simple et maintenable.
En réalité, la plupart des moteurs de production offrent la possibilité de créer, maintenir et sauvegarder des tâches de construction habituellement par l'intermédiaire d'une API de scripting. Cependant, ces fonctionnalités, bien que mentionnées dans le manuel utilisateur des moteurs de production, sont souvent négligées et non implémentées.
Les Avantages de l'Automatisation de la Création de Tâches de Construction
Il y a plusieurs avantages à utiliser une tâche de construction principale pour créer automatiquement de multiples tâches dans le but de faciliter le processus de construction d'intégration continue.
- Toutes les configurations de tâches de construction sont créées à partir d'un ensemble de gabarits de tâches ou de scripts. Ils peuvent être versionnés. La création d'une nouvelle tâche est alors une simple question d'utilisation des gabarits ou d'exécution de scripts. Ceci peut réduire le temps de création d'une tâche de façon significative (de plusieurs minutes à quelques secondes). Par conséquent, la modification de la configuration d'une tâche est simplifiée ; la modification de la configuration du gabarit de la tâche de construction garantit que toutes les tâches créées ultérieurement hériteront des changements.
- La cohérence entre toutes les configurations existantes de tâches de construction implique que leur mise à jour de manière globale - par l'intermédiaire d'outils ou de scripts - soit plus simple qu'avec un système incohérent et désordonné.
- Le développeur n'a pas nécessairement besoin d'une connaissance détaillée du moteur de production pour créer une nouvelle tâche de construction.
- La capacité de créer automatiquement et de supprimer des tâches de construction dans le cadre du cycle de vie de l'intégration continue Agile.
Discutons des points mentionnés :
Point 1 : Historisation de la Configuration d'une Tâche
C'est une bonne pratique que chaque composant d'un système d'IC devrait être placé dans un gestionnaire de configuration. Ceci inclut les systèmes de construction sous-jacents et les tâches de construction, pas seulement le code.
La plupart des moteurs de production stockent la configuration d'une tâche de construction dans un fichier sur le système maître. Ces fichiers sont au format XML et sont normalement accessibles directement par l'intermédiaire d'une interface frontale à travers une API REST quelconque. Certains moteurs de production ont une fonction intégrée permettant d'enregistrer la configuration d'une tâche sous forme de fichier vers n'importe quel emplacement.
Puisque la configuration de la tâche peut être sauvegardée dans un fichier, ce dernier peut être stocké dans un système de gestion de configuration (SCM). Toute modification de la configuration de la tâche peut être enregistrée, soit en modifiant le fichier directement, puis en le chargeant depuis le moteur de production, soit en modifiant la configuration de la tâche depuis le moteur de production, en la sauvegardant dans un fichier et en le transférant manuellement sur le SCM. La méthode utilisée dépend de la simplicité à accéder au fichier de configuration de la tâche directement depuis le moteur de production.
Une autre raison importante de stocker la configuration de la tâche dans un SCM est que dans le cas d'une défaillance catastrophique où toutes les configurations de tâches sont perdues, le système de construction peut être récupéré assez rapidement, et toutes les tâches, les logs de construction et l'historique des tâches peuvent être restaurés dans leur dernier - bon - état connu.
Point 2 : Maintenance
Bien sûr, il va sans dire que la maintenance d'un millier de tâches de différentes configurations serait un véritable casse-tête. C'est pourquoi il est important de normaliser les configurations des tâches. Si un changement est nécessaire et qu'il impacte un grand nombre de tâches similaires, l'écriture de scripts ou la création de tâches spéciales pour les modifier serait simple.
Cependant, avoir un millier de tâches dans un moteur de production n'est pas la meilleure stratégie d'IC. Nous discuterons de cette question au point 4.
Point 3 : Contrôle du Développeur
Bien que les développeurs soient encouragés à travailler de manière autonome, construisant leurs applications en utilisant un moteur de production centralisé, ils ont besoin de travailler avec des lignes directrices énoncées par le processus de construction.
Un développeur attend un retour rapide des modifications de son code et ainsi ne veut pas perdre de temps à jouer avec des moteurs de production et la configuration de tâches. Fournir aux développeurs une solution permettant de créer automatiquement des tâches de construction à l'aide d'un bouton de type "self-service" les aidera à atteindre leurs objectifs de développement plus rapidement.
Point 4 : Un Système d'IC Léger
Bien que les équipes de développement logiciel adoptent des méthodes agiles dans le développement de leurs produits, les moteurs de production avec lesquels elles travaillent ne sont pas nécessairement utilisés de la même manière, c'est-à-dire qu'un moteur de production correctement configuré ne devrait pas contenir des milliers de tâches de construction actives. Idéalement, les tâches devraient être créées à la demande dans le cadre du cycle de vie d'une construction d'IC. Tant qu'il est possible de recréer une tâche de construction à partir de n'importe quelle configuration de tâche historisée et que les anciennes constructions aient été conservées, c'est-à-dire les logs, artefacts, rapports de tests, etc., alors seulement une poignée de tâches devraient être présentes dans le moteur de production.
Bien sûr, une solution à la demande de création/suppression de tâches peut ne pas être un objectif réalisable, mais l'idée est que le nombre de tâches dans un moteur de production devrait être limité à un nombre maintenable.
Développement Quotidien
Le moteur de production régit les outils et processus nécessaires pour assister les développeurs dans leurs activités quotidiennes en ce qui concerne la construction et l'intégration continue. Des utilitaires permettant aux équipes de développement de créer des tâches de construction et fournissant de la flexibilité dans la configuration de tâches peuvent être installés tout en étant régis par les bonnes pratiques de développement logiciel.
Suite de Tâches de l'IC
Examinons les tâches typiques que les développeurs effectuent au cours de leur développement quotidien :
- Construction d'une base de référence
- Livraison de la base de référence
- Construction d'une branche de livraison (souvent combinée à la livraison de la base de référence)
- Création d'une branche de développement, construction de la branche
- Exécution des tests d'intégration
Bonnes pratiques de développement mises à part - c'est-à-dire développer sur une base de référence autant que possible, donc peu ou pas de branches de développement - les équipes de développement logiciel suivent généralement les tâches décrites ci-dessus en exécutant une suite de tâches de construction dans le moteur de production.
Or, c'est là que la création automatique de tâches ajoute une valeur énorme au processus de développement logiciel ; si un développeur voulait créer quatre à cinq tâches couvrant toutes les tâches de développement pour gérer ses opérations quotidiennes, cela lui prendrait une somme considérable de temps et d'efforts pour créer les tâches manuellement. Alors que la création automatique de tâches se fait en une fraction de seconde, le temps d'appuyer sur un bouton.
Quand mettre en place une Fonctionnalité de Création d'une Suite de Tâches en Libre-Service
Mettre en place une fonctionnalité de création d'une suite de tâches en libre-service est applicable pour les cas suivants :
- L'initialisation de nouveaux projets (ceux n'ayant jamais été construits avant)
- Des projets existants mais n'ayant jamais eu de tâches de construction configurées pour eux, c'est-à-dire les projets étant construits manuellement sur le poste du développeur.
Il y a aussi des cas pour lesquels mettre en place une fonctionnalité de création d'une suite de tâches en libre-service peut ne pas être applicable :
- Si un produit a seulement quelques tâches, c'est-à-dire de grosses applications monolithiques, alors il peut être considéré qu'il n'y a pas de valeur pour l'entreprise à dépenser une somme considérable de temps et d'efforts à concevoir, tester et déployer une fonctionnalité de création de tâches automatisée pour seulement ces quelques projets. Cependant, si l'entreprise se développe, l'architecture du produit deviendra de plus en plus complexe, nécessitant la mise en place de plus en plus d'axes de développement pour gérer la charge de travail supplémentaire. Par conséquent, le nombre de tâches dans le moteur de production augmentera inévitablement.
- Pour les projets ayant déjà des tâches, deux scénarios peuvent être considérés dans le traitement des tâches existantes dans le moteur de production.
- Supprimer les tâches existantes et les recréer avec l'utilitaire de création de suites de tâches, perdant ainsi tout l'historique des informations et logs de construction.
- Garder les tâches existantes et essayer de modifier leur configuration pour les faire correspondre avec celles créées par l'utilitaire de création de suites de tâches.
Dans tous les cas, il y aura toujours un coût dans la maintenance d'anciennes tâches de construction.
Mise en place d'une Fonctionnalité de Création d'une Suite de Tâches en Libre-Service dans un Moteur de Production
Nous avons abordé les avantages de créer automatiquement des tâches de construction. Voyons à présent comment nous pouvons mettre en place une telle fonctionnalité dans un moteur de production. Le principe devrait être le même pour construire des applications pour n’importe quelle langage, c'est-à-dire Java, .NET, etc.
Présentation du Formulaire de Création d'une Tâche de Création
Le formulaire de création est un moyen pour transmettre des informations à partir d'un moteur de production directement à une autre fonction ou des scripts qui réalisent les actions de création de tâches.
Idéalement, le plus d'informations possibles sur le projet devraient être fournies dès le départ. Cela permettra de réduire le coût de tout effort supplémentaire nécessaire plus tard pour ajouter une configuration supplémentaire aux tâches de construction nouvellement créées. Les informations telles que le nom du projet, l'emplacement du code source et des commutateurs de compilation spécifiques sont normalement requis. Ainsi, à la simple pression du bouton "Créer", les tâches sont créées quelques instants plus tard.
Mise en place d'un Moteur de Production
Nous allons maintenant discuter de comment une telle fonctionnalité de création de tâches peut être mise en œuvre dans un moteur de production. Les deux outils avec lesquels j'ai eu une expérience personnelle de la mise en place d'une fonctionnalité de création d'une suite de tâches sont Hudson et Anthill Pro 3.
Hudson / Jenkins
Pour plus de clarté, nous parlerons uniquement de Hudson, mais l'information est toute aussi pertinente pour Jenkins.
L'outil d'IC Hudson est devenu très populaire pour les managers de construction cherchant à minimiser leur budget de développement des ressources et ne voulant pas être liés à des licences coûteuses. Hudson définit la configuration de ses tâches de construction au format XML. Un fichier XML de configuration type de tâches est accessible depuis l'url de la tâche, c'est-à-dire http://nom-d-hote/nom-de-la-tache/config.xml
La plupart des sections du fichier de configuration sont évidentes. Les sections sont ajoutées par des modules complémentaires dans le fichier de configuration seulement lorsqu'ils sont utilisés dans l'IHM d'Hudson.
Ces fichiers de configuration peuvent être mis sous la forme de gabarits en remplaçant les informations spécifiques au projet par des variables. Plusieurs gabarits peuvent être utilisés pour effectuer des tâches différentes, à savoir la récupération de sources à partir de différents gestionnaires de versions, par exemple, Subversion ou GIT.
À présent, nous devons lier le formulaire de création d'une tâche de création à des scripts. Le diagramme ci-dessous montre le workflow :
Workflow de création de tâches avec Hudson
Le formulaire passe les informations aux scripts qui remplacent les variables dans les gabarits par les données appropriées. Les fichiers de configuration sont alors transférés à Hudson via une API. Plus de détails sur l'API peuvent être trouvés dans Hudson en ajoutant "api" à l'URL dans le navigateur, c'est-à-dire http://nom-d-hote/nom-de-la-tache/api.
Un exemple d'une commande - de l'API d'Hudson - de création d'une tâche et de transfert est indiqué ci-dessous :
curl –H Content-Type:application/xml –s –data @config.xml ${HUDSONURL}/createItem?name=hudsonjobname
Formulaire de création d'une tâche dans Hudson
Les tâches peuvent être ajoutées manuellement dans une nouvelle vue.
Vue des tâches dans Hudson
Quelques points à noter :
- Si la section de sécurité d'Hudson est configurée, veillez à ce que l'utilisateur "anonymous" ait l'autorisation "create job". Autrement, le transfert échouera au moment de l'authentification.
- Si les onglets d'Hudson sont utilisés pour afficher des groupes spécifiques de tâches, il ne sera pas possible de placer automatiquement les nouvelles tâches créées sous ces onglets, à l'exception de l'onglet générique "Tous" (ou n'importe quel onglet qui utilise une expression régulière). La mise à jour du fichier de configuration principal d'Hudson sera nécessaire ainsi qu'un redémarrage manuel de l'interface Hudson. Une fois que les tâches sont créées, elles peuvent alors être ajoutées manuellement à l'onglet approprié si désiré.
Les scripts peuvent être écrits dans n'importe quel langage tel que ANT, Perl, Groovy, etc. Ainsi, il suffit de suivre un ensemble de tâches relativement simples afin de créer les scripts effectuant les étapes décrites ci-dessus.
Un script ANT typique est illustré ci-dessous :
<project name="createjob" default="createHudsonjobsConfigs">
<!-- Script Ant mettant à jour les gabarits de tâches Hudson config.xml pour créer de nouvelles tâches dans Hudson -->
<!-- Récupère des propriétés externes à partir du formulaire de création d'Hudson -->
<property name="hudsonjobname" value="${HUDSON.JOB.NAME}" />
<property name="scmpath" value="${SCM.PATH}" />
<property name="mvngoals" value="${MVN.GOALS}" />
<!-- ...faire de même pour le reste des propriétés du formulaire Hudson -->
...
...
<property name="hudson.createItemUrl" value="http://hudson.server.location/createItem?name=" />
<!-- Ajout de tâches Ant externes -->
<taskdef resource="net/sf/antcontrib/antlib.xml"/>
<target name = "createHudsonjobsConfigs" description="crée un nouveau fichier config.xml à partir de paramètres fournit en entrée">
<mkdir dir="${hudsonjobname}"/>
<!-- itère sur chaque fichier de gabarit de tâches en remplaçant les variables dans les gabarits de taches avec des propriétés d'Hudson -->
<for list="CI-build-trunk,RC-build-branch" param="jobName">
<sequential>
<delete file="${hudsonjobname}/${configFile}" failonerror="false"></delete>
<copy file="../job-templates/@{jobName}-config.xml" tofile="${hudsonjobname}/${configFile}"/>
<replace file="${hudsonjobname}/${configFile}" token="$HUDSON.JOB.NAME" value="${hudsonjobname}"/>
<replace file="${hudsonjobname}/${configFile}" token="$SCM.PATH" value="${scmpath}"/>
<!-- ...faire de même avec le reste des variables du gabarit de la tâche -->
...
...
<antcall target="configXMLUpload">
<param name="job" value="@{jobName}"></param>
</antcall>
</sequential>
</for>
</target>
<!-- construit une commande de configuration de tâche et de transfert -->
<target name="configXMLUpload">
<echo>curl -H Content-Type:application/xml -s --data @config.xml${hudson.createItemUrl}${hudsonjobname}-${job}</echo>
<exec executable="curl" dir="${hudsonjobname}">
<arg value="-H" />
<arg value="Content-Type:application/xml"/>
<arg value="-s" />
<arg value="--data" />
<arg value="@config.xml" />
<arg value="${hudson.createItemUrl}${hudsonjobname}-${job}"/>
</exec>
</target>
</project>
Ci-dessous un gabarit d'une tâche Hudson typique avec des variables :
<?xml version='1.0' encoding='UTF-8'?>
<project>
<actions/>
<description>Construit $POM.ARTIFACTID</description>
...
...
<scm class="hudson.scm.SubversionSCM">
<locations>
<hudson.scm.SubversionSCM_-ModuleLocation>
<remote>$SCM.PATH/trunk</remote>
<local>.</local>
<depthOption>infinity</depthOption>
<ignoreExternalsOption>false</ignoreExternalsOption>
</hudson.scm.SubversionSCM_-ModuleLocation>
</locations>
</scm>
<assignedNode>$BUILD.FARM</assignedNode>
...
...
<builders>
<hudson.tasks.Maven>
<targets>$MVN.GOALS</targets>
<mavenName>$MVN.VERSION</mavenName>
<usePrivateRepository>false</usePrivateRepository>
</hudson.tasks.Maven>
</builders>
...
...
</project>
CI-build-trunk-config.xml Gabarit d'une tâche Hudson
Anthill Pro
Anthill Pro est un moteur de production et un outil d'intégration continue sous licence de la société UrbanCode, qui fournit à l'utilisateur un contrôle presque complet du paramétrage des tâches de construction via une IHM et une bibliothèque d'API étendue.
Le dernier produit de UrbanCode est uBuild, lequel est essentiellement une version réduite de Anthill et est équipé principalement pour l'intégration continue de construction de produits plutôt que son produit parent qui était originellement conçu pour gérer la totalité de la livraison continue. uBuild n'a pas la capacité de l'API qu'a Anthill, mais il est possible de créer un module faisant des choses semblables.
Dans Anthill, les tâches de construction sont appelées 'Workflows', lesquelles sont essentiellement une liste de tâches exécutées dans un ordre spécifique (sériel ou parallèle).
Le langage de scripting de l'API de Anthill est Beanshell qui est basé sur des méthodes standard de Java.
Les scripts Beanshell sont stockés dans l'IHM de Anthill et sont appelés depuis une tâche. La dernière version de Anthill permet de créer des modules personnalisés pouvant être développés dans n'importe quel langage de programmation.
Une tâche Anthill est créée en utilisant des appels à l'API qui construit toutes les fonctions nécessaires à ce workflow. Le script peut être particulièrement long puisque tous les aspects de la configuration du workflow doivent être paramétrés. Tout comme Hudson, les informations d'une tâche de construction sont collectées par l'intermédiaire d'un formulaire de création qui exécute un workflow principal, appelant des scripts Beanshell pour créer le workflow adéquat.
Vue des tâches dans Anthill
Formulaire de création de workflow de Anthill
Un script Beanshell Java typique est présenté ci-dessous :
private static Project createProject(User user) throws Exception {
// récupère des valeurs
String groupId = getAnthillProperty("GROUPID");
String artifactId = getAnthillProperty("ARTIFACTID");
String build_farm_env_name = "linux-build-farm";
String branchName = "branchName";
Workflow[] workflows = new Workflow[3];
// paramètre un projet
Project project = new Project(artifactId + "_" + branchName);
// détermine si le projet existe déjà et est actif
boolean isProjectActive;
try {
Project projectTest = getProjectFactoryInstance(artifactId + "_" + branchName);
isProjectActive = projectTest.isActive();
} catch (Exception err) {
isProjectActive = false;
}
if (!isProjectActive) {
project.setFolder(getFolder(groupId, artifactId));
setLifeCycleModel(project);
setEnvironmentGroup(project);
setQuietConfiguration(project);
String applications = getAnthillProperty("APPS");
// crée les propriétés du projet
createProjectProperty(project, "artifactId", artifactId, false, false);
// définit le groupe de serveurs pour le workflow et ajoute des propriétés de l'environnement
addPropertyToServerGroup(project, build_farm_env_name, applications);
project.store();
...
...
// crée le workflow de construction d'IC
String workflowName = "CI-build";
workflows[0] = createWorkflow(
project,
workflowName,
perforceClientFor(branchName, groupId, artifactId, workflowName) + buildLifeId,
perforceTemplateFor(branchName, groupId, artifactId, workflowName),
"${stampContext:maven_version}",
build_farm_env_name,
"CI-build Workflow Definition"
);
// ajoute un déclencheur au commit dans la branche lançant la construction
addRepositoryTrigger(workflows[0]);
// crée le workflow de la branche
workflowName = "Branch";
workflows[1] = createWorkflow(
project,
workflowName,
perforceClientFor(branchName, groupId, artifactId, workflowName) + buildLifeId,
perforceTemplateFor(branchName, groupId, artifactId, workflowName),
"From ${stampContext:maven_version}",
build_farm_env_name,
"Branch Workflow Definition"
);
// Crée le workflow de la release
workflowName = "Release";
workflows[2] = createWorkflow(
project,
workflowName,
perforceClientFor(branchName, groupId, artifactId, workflowName) + buildLifeId,
perforceTemplateFor(branchName, groupId, artifactId, workflowName),
"${stampContext:maven_release_version}",
build_farm_env_name,
"Release Workflow Definition"
);
...
...
} else {
// le projet existe déjà
String msg = "Project " + artifactId + "_" + branchName + " already exists - check project name and pom";
throw new RuntimeException (msg);
}
return project;
}
Exemple d'un script Beanshell Java permettant de créer un projet dans Anthill
Note : Il est également possible de créer une archive autonome de scripts Beanshell Java sous la forme d'un fichier jar qui est placé dans un dossier du serveur d'applications Anthill Pro. Des appels directs aux classes contenues dans le fichier jar peuvent ensuite être faits à partir d'une tâche shell dans l'application. Cela fonctionne bien, surtout parce que les scripts peuvent être testés unitairement avant d'être appliqués dans un environnement de développement réel.
Autres Outils
Donc, tant qu'il existe la possibilité de créer des tâches par l'intermédiaire d'une API ou d'une fonctionnalité de gabarits, la mise en œuvre décrite ici peut être appliquée de manière similaire à d'autres moteurs de production tels que Thoughtworks Go, JetBrains Teamcity et Atlassian Bamboo, pour n'en nommer que quelques-uns.
Le moteur de Production Agile ultime : mettre en œuvre la Philosophie du Lean dans un Moteur de Production
Un avantage mentionné précédemment dans cet article évoquait l'idée de créer automatiquement des projets d'IC à la demande, puis de les supprimer lorsqu'ils ne sont plus utiles. Cela permettrait de réduire considérablement la quantité de tâches de construction dans le moteur de production.
Je n'ai pas encore mis en œuvre une méthode lean/agile pour la création et la suppression de tâches d'un moteur de production, par conséquent les défis techniques de mettre en œuvre une telle fonctionnalité n'ont pas encore été réalisés. Cependant, tout ce qui a été discuté dans cet article peut conduire à la mise en œuvre d'une telle solution. En fait, le moteur de production Atlassian Bamboo a la particularité de détecter la création de branches à partir d'une base principale, puis de créer automatiquement une tâche appropriée pour la construire.
En conclusion
Nous avons discuté de la façon de mettre en place des fonctionnalités pour créer d'autres tâches qui font partie de la stratégie de livraison continue d'une entreprise.
- Une approche automatisée pour créer des tâches dans un moteur de production devrait être adoptée dans le cadre d'opérations quotidiennes de développement logiciel.
- La création automatique de tâches permet de gagner du temps et permet au développeur de s'occuper de choses plus importantes.
- La configuration cohérente de tâches de construction conduit à une maintenance plus facile et entraîne des pratiques de développement cohérentes à travers une entreprise.
- La création automatique de tâches peut finalement conduire à une véritable adoption du développement logiciel agile, directement jusqu'au niveau du moteur de production.
A propos de l'Auteur
Martin Peston est manager de construction et d'intégration continue chez Gamesys, la société leader dans les jeux en ligne et mobiles au Royaume-Uni, propriétaire de la populaire marque de bingo Jackpotjoy et de jeux sociaux à succès tel que Friendzys sur Facebook.
Martin a 15 ans d'expérience en informatique dans plusieurs secteurs, dont l'espace, la défense, la santé et les jeux. Il a consacré près de la moitié de sa carrière aux moteurs de production et s'investit avec passion pour apporter les meilleures pratiques de livraison continue aux entreprises de développement logiciel.
Durant son temps libre, Martin est un astronome amateur passionné et auteur du manuel "A User's Guide to the Meade LXD55 and LXD75 Telescopes" publié par Springer en 2007.