Utilisation du contrôle de source

De Appmethod Topics
Aller à : navigation, rechercher

Remonter à Gestionnaire de l'historique

Cette rubrique fournit une présentation des concepts de contrôle de source généraux qui sont homogènes avec un certain nombre de systèmes de contrôle de source, aussi connus comme des systèmes de gestion de la configuration logicielle (SCM) et de modifications automatisées.

Remarque : Appmethod vous offre la fonctionnalité de contrôle de version par le biais de plusieurs systèmes de contrôle de version :

Principes du contrôle de source

Chaque système de contrôle de source est composé d'un ou de plusieurs référentiels centralisés et de clients. Un référentiel est une base de données qui contient non seulement les fichiers de données mais aussi la structure de chaque projet que vous avez défini.

La plupart des systèmes de contrôle de source respectent un concept de projet logique, dans lequel des fichiers sont stockés, généralement dans une ou plusieurs structures arborescentes de répertoires. Un projet d'un système de contrôle de source peut contenir un ou plusieurs projets Appmethod en plus d'autres documents ou artefacts. De plus, le système applique son propre système d'authentification des utilisateurs ou tire profit de l'authentification proposée par le système d'exploitation sous-jacent. Cela permet au système de contrôle de source de gérer un journal d'audit ou des captures des modifications de chaque fichier. Ces captures sont typiquement appelées des diffs, pour différences. En ne stockant que les différences, le système de contrôle de source peut garder la trace de toutes les modifications avec des exigences minimales de stockage. Quand vous voulez voir une version complète de votre fichier, le système effectue une fusion des différences et vous présente une vue unifiée. Au niveau physique, ces différences sont stockées dans des fichiers distincts jusqu'à ce que vous soyez prêt à fusionner de manière permanente vos mises à jour, au moment où vous effectuez une action de validation.

Cette approche vous permet à vous et à d'autres membres de l'équipe de travailler en parallèle, en codant simultanément dans plusieurs projets partagés sans risque que les modifications apportées au code par un membre de l'équipe ne vienne écraser les modifications d'un autre membre. Les systèmes de contrôle de source, dans leur forme la plus basique, vous protègent des conflits de code et de la perte de code source antérieur. La plupart des systèmes de contrôle de source proposent les outils pour gérer les fichiers de code avec des fonctionnalités d'archivage et d'extraction, la résolution de conflits et des états. Toutefois ,la plupart des systèmes ne proposent pas la résolution des conflits de logique ou la gestion des constructions. Pour des détails sur les possibilités de votre système de contrôle de source, reportez-vous à sa documentation fournie par son éditeur.

Généralement, les systèmes de contrôle de source ne vous permettent de comparer et de fusionner que les révisions des fichiers texte, tels que les fichiers de code source, les documents HTML ou XML. Certains systèmes de contrôle de source vous permettent d'inclure des fichiers binaires, tels que des images ou du code compilé, dans les projets que vous placez sous contrôle. Cependant, vous ne pouvez pas comparer ou fusionner les révisions de fichiers binaires. Si vous avez besoin d'effectuer d'autres opérations que le stockage et l'extraction de révisions spécifiques de ces types de fichiers, vous devriez songer à créer un système manuel de suivi des modifications apportées aux fichiers binaires.

Principes des référentiels

Les systèmes de contrôle de source stockent les copies des fichiers source et les fichiers de différences dans un référentiel de base de données. Avec certains systèmes comme CVS ou VSS, le référentiel est une structure logique constituée d'un ensemble de fichiers linéaires et de fichiers de contrôle. Dans d'autres systèmes, les référentiels sont des instances d'un système de base de données précis comme InterBase, Microsoft Access, MS SQL Server, IBM DB2 ou Oracle.

Les référentiels sont généralement stockés sur un serveur distant, ce qui permet à plusieurs utilisateurs de se connecter, d'extraire des fichiers, de les archiver ou d'effectuer d'autres tâches simultanément. Vous devez donc vous assurer que vous établissez la liaison avec non seulement le serveur mais avec l'instance de la base de données. Consultez vos administrateurs réseau, système et base de données pour vous assurer que votre machine a les pilotes et les programmes de connectivité nécessaires en plus du programme côté client du système de contrôle de source.

Certains systèmes de contrôle de source vous permettent de créer un référentiel local dans lequel vous conservez une capture de vos projets. Au fil du temps, l'image locale de vos projets diffère de celle du référentiel distant. Vous pouvez établir une stratégie pour fusionner et valider les modifications depuis votre référentiel local vers le référentiel distant.

Généralement, il n'est pas prudent de donner à chaque membre de votre équipe un référentiel distinct pour un projet partagé. Si vous travaillez chacun sur des projets complètement distincts et si chacun veut contrôler localement les sources, vous pouvez utiliser des référentiels locaux individuels. Vous pouvez aussi créer plusieurs référentiels sur un serveur distant, ce qui permet une gestion centralisée pour les sauvegardes et la maintenance.

Utilisation des projets

Les systèmes de contrôle de source, comme les environnements de développement, utilisent le concept de projet pour organiser et suivre des groupes de fichiers associés. Quel que soit le système de contrôle de source utilisé, vous devez créer un projet conservant les définitions et les emplacements de vos fichiers. Vous pouvez également créer des projets dans Appmethod pour organiser les divers assemblages et les fichiers de code source d'une application donnée. Appmethod stocke les paramètres du projet dans un fichier projet. Vous pouvez stocker ce fichier dans votre projet du système de contrôle de source en plus des divers fichiers de code que vous créez. Vous pouvez partager votre fichier projet avec tous les développeurs de votre équipe, ou chacun peut gérer son propre fichier projet.

La plupart des systèmes de contrôle de source considèrent les fichiers projet de l'environnement de développement comme des binaires, que ce soit réellement ou pas des fichiers binaires. En conséquence, lorsque vous archivez un fichier projet dans un référentiel de système de contrôle de source, le système de contrôle de source remplace les anciennes versions du fichier par la nouvelle version sans essayer de fusionner les modifications. Il en va de même lors de l'extraction d'un projet ou du fichier projet ; la nouvelle version du fichier projet remplace l'ancienne version sans fusion.

Utilisation des fichiers

Le fichier est l'objet de plus bas niveau géré par un système de contrôle de source. Tout code que vous voulez gérer avec le système de contrôle de source doit être contenu dans un fichier. La plupart des systèmes de contrôle de source stockent les fichiers dans une structure arborescente logique. Certains systèmes, comme CVS, utilisent en fait des termes comme branche, pour désigner un niveau de répertoire. Vous pouvez créer des fichiers dans un projet Appmethod et les inclure dans votre système de contrôle de source ou extraire des fichiers existants depuis le système de contrôle de source. Vous pouvez placer tout un répertoire dans le système de contrôle de source, après quoi vous pouvez extraire les fichiers individuellement, en groupe ou des arborescences de sous-répertoires complètes. Appmethod vous donne le contrôle sur vos fichiers à deux niveaux - au niveau du projet dans Appmethod et dans le système de contrôle de source, via l'interface Appmethod avec le système de contrôle de source.

Remarque : La vue Historique fournit des informations de révision sur vos fichiers source locaux. La vue Historique peut être utilisée pour suivre les modifications apportées aux fichiers lorsque vous travaillez dessus dans le concepteur ou dans l'éditeur de code.

Voir aussi