public marks

PUBLIC MARKS from holyver with tag méthodologie

22 October 2006

Integration continue - XP-Swiss

(via)
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.

15 October 2006

Getting ready for SLAs

While it is true that organizations should try to establish service-level agreements as soon as possible, it is a serious mistake to begin the process before your organization is ready. If you are considering negotiating SLAs, you need to make sure you are prepared. Before you can negotiate an SLA, it is essential that there be a solid management infrastructure in place. That means all of the management functions are there, in some form, for each of the resources used to deliver the service.

Le Service Level Agreement ou SLA

(via)
Le Service Level Agreement ou SLA est une expression anglaise qui peut être traduite par « Accord de Niveau de Service » ou par « Engagement de Service », ou encore plus simplement « Convention de Service ». Le SLA est le contrat ou la partie du contrat spécifiant l’ensemble des niveaux de services à fournir par le prestataire informatique au(x) client(s). Il s’agit d’un engagement formel et contraignant, établi entre un prestataire et son (ses) client(s).

holyver's TAGS related to tag méthodologie

development +   doc +   practice +   server +   service +   sla +