Automatisation de testL'automatisation de test permet de jouer à volonté des tests de régression à la suite de la livraison d'une nouvelle version d'une application. L'automatisation d'un test n'a de sens que si le test répond à un certain nombre de critères : le test est systématique : il doit être exécuté à chaque nouvelle version de l'application. le test est répétitif : il est présent dans de nombreux scénarios de test. le test est automatisable : il est possible techniquement de faire jouer le test par un robot.
Feature toggleA feature toggle in software development provides an alternative to maintaining multiple feature branches in source code. A condition within the code enables or disables a feature during runtime. In agile settings the toggle is used in production, to switch on the feature on demand, for some or all the users. Thus, feature toggles do make it easier to release often. Advanced roll out strategies such as canary roll out and A/B testing are easier to handle.
Test driven developmentTest-Driven Development (TDD), ou développement piloté par les tests en français, est une méthode de développement de logiciel qui consiste à concevoir un logiciel par des itérations successives très courtes (ou petits pas), telles que chaque itération est accomplie en formulant un sous-problème à résoudre sous forme d'un test avant d'écrire le code source correspondant, et où le code est continuellement remanié dans une volonté de simplification. À l'origine, il s'agissait simplement d'écrire les tests avant de coder, et cette méthode s'appelait le Test-First Design.
Moteur de productionUn moteur de production est un logiciel dont la fonction principale consiste à automatiser (ordonnancer et piloter) l'ensemble des actions (préprocessing, compilation, éditions des liens, etc.) contribuant, à partir de données sources, à la production d'un ensemble logiciel opérationnel. Un moteur de production se distingue d'un simple script dans la mesure où il a pour objet : de favoriser une production optimale (réduite aux seules actions nécessaires) de permettre une flexibilité de production (production partielle sans avoir besoin de modifier le descriptif de production) tout en assurant la complétude.
Release engineeringRelease engineering, frequently abbreviated as RE or as the clipped compound Releng, is a sub-discipline in software engineering concerned with the compilation, assembly, and delivery of source code into finished products or other software components. Associated with the software release life cycle, it was said by Boris Debic of Google Inc. that release engineering is to software engineering as manufacturing is to an industrial process: Release engineering is the difference between manufacturing software in small teams or startups and manufacturing software in an industrial way that is repeatable, gives predictable results, and scales well.
Gestion des mises en productionLa gestion des mises en production, c’est avoir une vue complète et totale d’un changement apporté à un service (Au sens ITIL du terme, c'est-à-dire, une application métier, un composant de l'infrastructure, ...) et s’assurer que tous les aspects d’une nouvelle version matérielle et logicielle aussi bien technique que non technique soient pris en considération. Il existe des modifications dans les versions, et dans ces modifications il en existe trois types : le full release : nouvelle version distribuée entièrement, une delta release (patch) et ce que l’on appelle le package release (un mélange de full et de delta release).
Branche (gestion de configuration)En gestion de configuration logicielle, une branche est une dérivation dans l'histoire de l'évolution des éléments de configuration. Une branche est une évolution d'un élément ayant pour origine une version précise, produisant une «branche de version». Une branche de version correspond à un axe d'évolution de versions. Elle est rattachée à une branche source et peut découler sur plusieurs sous-branches. La gestion de l'ensemble des branches et des versions d'un produit constitue le versionnage (versioning en anglais) et est l'objet de la gestion de configuration.
Déploiement continuLe déploiement continu (continuous deployment, CD) est une approche d'ingénierie logicielle dans laquelle les fonctionnalités logicielles sont livrées fréquemment par le biais de déploiements automatisés. Le déploiement continu diffère de la livraison continue, une approche similaire dans laquelle des fonctionnalités logicielles sont également livrées fréquemment et considérées comme pouvant potentiellement être déployées, mais qui ne le sont pas pour autant (le déploiement restant dans ce cas un processus manuel).
Coding best practicesCoding best practices or programming best practices are a set of informal rules (best practices) that many software developers in computer programming follow to improve software quality. Many computer programs remain in use for long periods of time, so any rules need to facilitate both initial development and subsequent maintenance and enhancement of source code by people other than the original authors. In the ninety-ninety rule, Tom Cargill is credited with an explanation as to why programming projects often run late: "The first 90% of the code accounts for the first 90% of the development time.
Distributed version controlIn software development, distributed version control (also known as distributed revision control) is a form of version control in which the complete codebase, including its full history, is mirrored on every developer's computer. Compared to centralized version control, this enables automatic management branching and merging, speeds up most operations (except pushing and pulling), improves the ability to work offline, and does not rely on a single location for backups.
