PUBLIC MARKS with tag Devs

Recently, I was asked to outline a plan for a structured process for software development that maximizes productivity and reduces bugs that reach the user. This was originally an internal OhioLINK document, but the process described is pretty traditional and others might find a use for this as well. You are welcome to use this; please honor the Creative Commons licensing terms and contact me in advance if you need something different.

Zend Debugger is a full-featured php debugger engine, an interactive tool that helps you debug PHP scripts. It works with a production and/or development web server and allows you to debug your scripts locally or remotely, from an IDE or the console. To get the debugger to work you need to install the debugger engine to run in the PHP interpreter (server part), and configure the debugger client to communicate with the engine.

Avant de commencer avec l'intégration continue, il faut comprendre l'architecture "idéale" de développement d'une application. Elle se compose de cinq environnements : * les postes des développeurs (dits "locaux"), avec les différents outils traditionnels (IDE, outils de modèlisation de base de données, éditeurs XML, ...) * l'environnement de développement. Il est réservé aux développeurs qui en ont tous les droits (administrateurs). On verra que c'est l'environnement cible de l'intégration continue. Il est ainsi toujours à jour avec la dernière version disponible de l'application. De plus son état est souvent plus ou moins stable (redémarrage fréquent des applications, données volatiles insérées par les développeurs dans le cadre de leurs tests, ...) * l'environnement de test à destination du client (par exemple l'équipe marketing). Ce dernier valide le bon développement de l'application par rapport à ses besoins. Dans le cadre d'un développement itératif, il permet surtout de découvrir à temps les besoins réels du client qui sont trop souvent mal exprimés ou incomplets. Une nouvelle version de l'application est déployée depuis l'environnement de développement dès que l'appli est estimée stable et qu'elle contient suffisement de nouveautés ou corrections de bugs par rapport à la version précédente. Ces déploiements sont tout de même fréquents (toutes les 1 à 2 semaines) et sont généralement effectués manuellement à la demande du chef de projet. On offre alors généralement un fichier changes.txt qui décrit les différentes évolutions et corrections de bugs apportées depuis la version précédente. * l'environnement de pré-production pour tester la version finale de l'application. Il reproduit à l'identique l'environnement de production (nombre de machines, processeurs, mémoires, versions des applications, ...). Il permet de réaliser les tests de charge et de valider la bonne exécution de l'application lors du passage en production. * l'environnement de production accessible par les clients.