Contrôle de code source (création d’applications cloud Real-World avec Azure)

  • Article

par Rick Anderson, Tom Dykstra

Télécharger corriger le projet ou télécharger le livre électronique

Le livre électronique Building Real World Cloud Apps with Azure est basé sur une présentation développée par Scott Guthrie. Il explique 13 modèles et pratiques qui peuvent vous aider à développer des applications web pour le cloud. Pour plus d’informations sur le livre électronique, consultez le premier chapitre.

Le contrôle de code source est essentiel pour tous les projets de développement cloud, pas seulement pour les environnements d’équipe. Vous ne pensez pas à modifier le code source ou même un document Word sans une fonction d’annulation et des sauvegardes automatiques, et le contrôle de code source vous offre ces fonctions au niveau du projet où elles peuvent gagner encore plus de temps en cas de problème. Avec les services de contrôle de code source cloud, vous n’avez plus à vous soucier de la configuration compliquée et vous pouvez utiliser Azure Repos contrôle de code source gratuit pour un maximum de 5 utilisateurs.

La première partie de ce chapitre explique trois bonnes pratiques clés à garder à l’esprit :

Le reste du chapitre fournit quelques exemples d’implémentations de ces modèles dans Visual Studio, Azure et Azure Repos :

Traiter les scripts Automation comme du code source

Lorsque vous travaillez sur un projet cloud, vous changez fréquemment les choses et vous souhaitez être en mesure de réagir rapidement aux problèmes signalés par vos clients. Pour répondre rapidement, vous devez utiliser des scripts d’automatisation, comme expliqué dans le chapitre Automatiser tout . Tous les scripts que vous utilisez pour créer votre environnement, y déployer, le mettre à l’échelle, etc., doivent être synchronisés avec le code source de votre application.

Pour synchroniser les scripts avec le code, stockez-les dans votre système de contrôle de code source. Ensuite, si vous avez besoin de restaurer des modifications ou d’apporter une correction rapide au code de production qui est différent du code de développement, vous n’avez pas besoin de perdre du temps à essayer de rechercher quels paramètres ont changé ou quels membres de l’équipe ont des copies de la version dont vous avez besoin. Vous êtes assuré que les scripts dont vous avez besoin sont synchronisés avec la base de code pour laquelle vous en avez besoin, et vous êtes assuré que tous les membres de l’équipe travaillent avec les mêmes scripts. Ensuite, si vous avez besoin d’automatiser le test et le déploiement d’un correctif à chaud pour la production ou le développement de nouvelles fonctionnalités, vous disposez du script approprié pour le code qui doit être mis à jour.

Ne case activée pas dans les secrets

Un dépôt de code source est généralement accessible à un trop grand nombre de personnes pour qu’il soit un emplacement sécurisé approprié pour les données sensibles telles que les mots de passe. Si les scripts s’appuient sur des secrets tels que des mots de passe, paramétrez ces paramètres afin qu’ils ne soient pas enregistrés dans le code source et stockez vos secrets ailleurs.

Par exemple, Azure vous permet de télécharger des fichiers qui contiennent des paramètres de publication afin d’automatiser la création de profils de publication. Ces fichiers incluent des noms d’utilisateur et des mots de passe autorisés à gérer vos services Azure. Si vous utilisez cette méthode pour créer des profils de publication et si vous case activée dans ces fichiers au contrôle de code source, toute personne ayant accès à votre dépôt peut voir ces noms d’utilisateur et mots de passe. Vous pouvez stocker le mot de passe en toute sécurité dans le profil de publication lui-même, car il est chiffré et il se trouve dans un fichier .pubxml.user qui, par défaut, n’est pas inclus dans le contrôle de code source.

Structurer les branches sources pour faciliter le flux de travail DevOps

La façon dont vous implémentez des branches dans votre dépôt affecte votre capacité à développer de nouvelles fonctionnalités et à résoudre les problèmes en production. Voici un modèle que de nombreuses équipes de taille moyenne utilisent :

Structure de branche source

La branche main correspond toujours au code en production. Les branches situées sous main correspondent à différentes étapes du cycle de vie du développement. La branche de développement est l’endroit où vous implémentez de nouvelles fonctionnalités. Pour une petite équipe, il se peut que vous ayez simplement main et le développement, mais nous recommandons souvent aux utilisateurs d’avoir une branche intermédiaire entre le développement et main. Vous pouvez utiliser la préproduction pour le test final de l’intégration avant qu’une mise à jour ne soit déplacée en production.

Pour les grandes équipes, il peut y avoir des branches distinctes pour chaque nouvelle fonctionnalité ; pour une équipe plus petite, vous pouvez avoir tout le monde à se connecter à la branche de développement.

Si vous avez une branche pour chaque fonctionnalité, lorsque la fonctionnalité A est prête, vous fusionnez son code source dans la branche de développement et dans les autres branches de fonctionnalité. Ce processus de fusion de code source peut prendre beaucoup de temps et, pour éviter ce travail tout en conservant des fonctionnalités distinctes, certaines équipes implémentent une alternative appelée bascule de fonctionnalité (également appelée indicateurs de fonctionnalité). Cela signifie que tout le code de toutes les fonctionnalités se trouve dans la même branche, mais que vous activez ou désactivez chaque fonctionnalité à l’aide de commutateurs dans le code. Par exemple, supposons que la fonctionnalité A est un nouveau champ pour corriger les tâches d’application et que la fonctionnalité B ajoute une fonctionnalité de mise en cache. Le code des deux fonctionnalités peut se trouver dans la branche de développement, mais l’application n’affiche le nouveau champ que lorsqu’une variable a la valeur true, et elle n’utilise la mise en cache que lorsqu’une autre variable est définie sur true. Si la fonctionnalité A n’est pas prête à faire l’objet d’une promotion, mais que la fonctionnalité B est prête, vous pouvez promouvoir tout le code en production en activant la fonctionnalité A et en activant la fonctionnalité B. Vous pouvez ensuite terminer la fonctionnalité A et la promouvoir ultérieurement, le tout sans fusion de code source.

Que vous utilisiez ou non des branches ou des bascules pour les fonctionnalités, une structure de branche comme celle-ci vous permet de transmettre votre code du développement à la production de manière agile et reproductible.

Cette structure vous permet également de réagir rapidement aux commentaires des clients. Si vous devez apporter une solution rapide à la production, vous pouvez également le faire efficacement de manière agile. Vous pouvez créer une branche hors de main ou de préproduction et, lorsqu’elle est prête, fusionnez-la dans main et vers le bas dans des branches de développement et de fonctionnalités.

Branche correctif logiciel

Sans une structure de branche comme celle-ci avec sa séparation des branches de production et de développement, un problème de production pourrait vous mettre dans la position de devoir promouvoir de nouveau code de fonctionnalité avec votre correctif de production. Le nouveau code de fonctionnalité n’est peut-être pas entièrement testé et prêt pour la production et vous devrez peut-être effectuer beaucoup de travail pour sauvegarder les modifications qui ne sont pas prêtes. Vous devrez peut-être retarder votre correctif pour tester les modifications et les préparer au déploiement.

Vous verrez ensuite des exemples d’implémentation de ces trois modèles dans Visual Studio, Azure et Azure Repos. Il s’agit d’exemples plutôt que d’instructions détaillées sur la procédure à suivre; Pour obtenir des instructions détaillées qui fournissent tout le contexte nécessaire, consultez la section Ressources à la fin du chapitre.

Ajouter des scripts au contrôle de code source dans Visual Studio

Vous pouvez ajouter des scripts au contrôle de code source dans Visual Studio en les incluant dans un dossier de solution Visual Studio (en supposant que votre projet est dans le contrôle de code source). Voici une façon de le faire.

Créez un dossier pour les scripts dans votre dossier de solution (le même dossier que celui qui contient votre fichier .sln ).

Dossier Automation

Copiez les fichiers de script dans le dossier.

Contenu du dossier Automation

Dans Visual Studio, ajoutez un dossier de solution au projet.

Sélection du menu Nouveau dossier de solution

Et ajoutez les fichiers de script au dossier solution.

Sélection du menu Ajouter un élément existant

Boîte de dialogue Ajouter un élément existant

Les fichiers de script sont désormais inclus dans votre projet et le contrôle de code source suit leurs modifications de version ainsi que les modifications de code source correspondantes.

Stocker des données sensibles dans Azure

Si vous exécutez votre application dans un site web Azure, une façon d’éviter de stocker les informations d’identification dans le contrôle de code source consiste à les stocker dans Azure à la place.

Par exemple, l’application Fix It stocke dans son fichier Web.config deux chaînes de connexion qui auront des mots de passe en production et une clé qui donne accès à votre compte de stockage Azure.

<connectionStrings>
  <add name="DefaultConnection" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItMembership.mdf;Initial Catalog=MyFixItMembership;Integrated Security=True" providerName="System.Data.SqlClient" />
  <add name="appdb" connectionString="Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\MyFixItTasks.mdf;Initial Catalog=aspnet-MyFixItTasks;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
<appSettings>
  <add key="webpages:Version" value="3.0.0.0" />
  <add key="webpages:Enabled" value="false" />
  <add key="ClientValidationEnabled" value="true" />
  <add key="UnobtrusiveJavaScriptEnabled" value="true" />
  <add key="StorageAccountName" value="fixitdemostorage" />
  <add key="StorageAccountAccessKey" value="[accesskeyvalue]" />
</appSettings>

Si vous placez des valeurs de production réelles pour ces paramètres dans votre fichier Web.config , ou si vous les placez dans le fichier Web.Release.config pour configurer une transformation Web.config pour les insérer pendant le déploiement, elles seront stockées dans le référentiel source. Si vous entrez les chaînes de connexion à la base de données dans le profil de publication de production, le mot de passe se trouve dans votre fichier .pubxml . (Vous pouvez exclure le fichier .pubxml du contrôle de code source, mais vous perdez l’avantage du partage de tous les autres paramètres de déploiement.)

Azure vous offre une alternative pour les sections appSettings et chaînes de connexion du fichier Web.config . Voici la partie pertinente de l’onglet Configuration d’un site web dans le portail de gestion Azure :

appSettings et connectionStrings dans le portail

Lorsque vous déployez un projet sur ce site web et que l’application s’exécute, toutes les valeurs que vous avez stockées dans Azure remplacent les valeurs contenues dans le fichier Web.config.

Vous pouvez définir ces valeurs dans Azure à l’aide du portail de gestion ou de scripts. Le script d’automatisation de la création d’environnement que vous avez vu dans le chapitre Automatiser tout crée une base de données Azure SQL, obtient les chaînes de connexion de stockage et d’SQL Database, et stocke ces secrets dans les paramètres de votre site web.

# Configure app settings for storage account and New Relic
$appSettings = @{ `
    "StorageAccountName" = $storageAccountName; `
    "StorageAccountAccessKey" = $storage.AccessKey; `
    "COR_ENABLE_PROFILING" = "1"; `
    "COR_PROFILER" = "{71DA0A04-7777-4EC6-9643-7D28B46A8A41}"; `
    "COR_PROFILER_PATH" = "C:\Home\site\wwwroot\newrelic\NewRelic.Profiler.dll"; `
    "NEWRELIC_HOME" = "C:\Home\site\wwwroot\newrelic" `
}

# Configure connection strings for appdb and ASP.NET member db
$connectionStrings = ( `
    @{Name = $sqlAppDatabaseName; Type = "SQLAzure"; ConnectionString = $sql.AppDatabase.ConnectionString}, `
    @{Name = "DefaultConnection"; Type = "SQLAzure"; ConnectionString = $sql.MemberDatabase.ConnectionString}
)

Notez que les scripts sont paramétrés afin que les valeurs réelles ne soient pas conservées dans le référentiel source.

Lorsque vous exécutez localement dans votre environnement de développement, l’application lit votre fichier Web.config local et votre chaîne de connexion pointe vers une base de données SQL Server LocalDB dans le dossier App_Data de votre projet web. Lorsque vous exécutez l’application dans Azure et que l’application tente de lire ces valeurs à partir du fichier Web.config, ce qu’elle obtient et utilise sont les valeurs stockées pour le site web, pas ce qui se trouve réellement dans Web.config fichier.

Utiliser Git dans Visual Studio et Azure DevOps

Vous pouvez utiliser n’importe quel environnement de contrôle de code source pour implémenter la structure de branchement DevOps présentée précédemment. Pour les équipes distribuées, un système de contrôle de version distribué (DVCS) peut fonctionner le mieux ; pour d’autres équipes, un système centralisé peut fonctionner mieux.

Git est un système de contrôle de version distribué populaire. Lorsque vous utilisez Git pour le contrôle de code source, vous disposez d’une copie complète du dépôt avec tout son historique sur votre ordinateur local. De nombreuses personnes préfèrent cela, car il est plus facile de continuer à travailler lorsque vous n’êtes pas connecté au réseau. Vous pouvez continuer à effectuer des validations et des restaurations, créer et changer de branches, etc. Même lorsque vous êtes connecté au réseau, il est plus facile et plus rapide de créer des branches et de changer de branche lorsque tout est local. Vous pouvez également effectuer des validations et des restaurations locales sans avoir d’impact sur d’autres développeurs. Vous pouvez également effectuer des validations par lots avant de les envoyer au serveur.

Azure Repos offre à la fois Git et Team Foundation Version Control (TFVC ; contrôle de code source centralisé). Prise en main d’Azure DevOps ici.

Visual Studio 2017 inclut une prise en charge intégrée et de première classe de Git. Voici une démonstration rapide de la façon dont cela fonctionne.

Avec un projet ouvert dans Visual Studio, cliquez avec le bouton droit sur la solution dans Explorateur de solutions, puis choisissez Ajouter une solution au contrôle de code source.

Ajouter une solution au contrôle de code source

Visual Studio vous demande si vous souhaitez utiliser TFVC (contrôle de version centralisé) ou Git.

Choisir le contrôle de code source

Quand vous sélectionnez Git et cliquez sur OK, Visual Studio crée un référentiel Git local dans votre dossier de solution. Le nouveau dépôt n’a pas encore de fichiers ; vous devez les ajouter au dépôt en effectuant un commit Git. Cliquez avec le bouton droit sur la solution dans Explorateur de solutions, puis cliquez sur Valider.

Commiter

Visual Studio met automatiquement en phase tous les fichiers projet pour la validation et les répertorie dans Team Explorer dans le volet Modifications incluses. (S’il y en avait que vous ne vouliez pas inclure dans le commit, vous pouvez les sélectionner, cliquer avec le bouton droit, puis cliquer sur Exclure.)

Team Explorer

Entrez un commentaire de validation, puis cliquez sur Valider. Visual Studio exécute la validation et affiche l’ID de validation.

Changements de Explorer d’équipe

Maintenant, si vous modifiez du code pour qu’il soit différent de ce qui se trouve dans le dépôt, vous pouvez facilement afficher les différences. Cliquez avec le bouton droit sur un fichier que vous avez modifié, sélectionnez Comparer avec unmodified et vous obtenez un affichage de comparaison qui affiche votre modification non validée.

Comparer avec Unmodified

Différences montrant les modifications

Vous pouvez facilement voir les modifications que vous apportez et les case activée.

Supposons que vous deviez créer une branche . Vous pouvez également le faire dans Visual Studio. Dans Team Explorer, cliquez sur Nouvelle branche.

Équipe Explorer Nouvelle branche - Image 1

Entrez un nom de branche, cliquez sur Créer une branche et, si vous avez sélectionné Checkout branch , Visual Studio extrait automatiquement la nouvelle branche.

Équipe Explorer Nouvelle branche - Image 2

Vous pouvez maintenant apporter des modifications aux fichiers et les case activée dans cette branche. Et vous pouvez facilement basculer entre les branches et Visual Studio synchronise automatiquement les fichiers avec la branche que vous avez extraite. Dans cet exemple, le titre de la page web dans _Layout.cshtml a été remplacé par « Correctif à chaud 1 » dans la branche HotFix1.

Branche Hotfix1

Si vous revenez à la branche main, le contenu du fichier _Layout.cshtml revient automatiquement à ce qu’il se trouve dans la branche main.

main branche

Voici un exemple simple de la façon dont vous pouvez créer rapidement une branche et faire des allers-retours entre les branches. Cette fonctionnalité permet un flux de travail hautement agile à l’aide de la structure de branche et des scripts d’automatisation présentés dans le chapitre Automatiser tout . Par exemple, vous pouvez travailler dans la branche Développement, créer une branche de correctif à chaud hors de main, basculer vers la nouvelle branche, y apporter vos modifications et les valider, puis revenir à la branche Développement et continuer ce que vous faisiez.

Ce que vous avez vu ici, c’est comment vous travaillez avec un dépôt Git local dans Visual Studio. Dans un environnement d’équipe, vous poussez généralement les modifications vers un référentiel commun. Les outils Visual Studio vous permettent également de pointer vers un dépôt Git distant. Vous pouvez utiliser GitHub.com à cette fin, ou vous pouvez utiliser Git et Azure Repos intégrées à toutes les autres fonctionnalités Azure DevOps telles que le suivi des éléments de travail et des bogues.

Ce n’est pas la seule façon d’implémenter une stratégie de création de branches agile, bien sûr. Vous pouvez activer le même workflow agile à l’aide d’un référentiel de contrôle de code source centralisé.

Résumé

Mesurez la réussite de votre système de contrôle de code source en fonction de la rapidité avec laquelle vous pouvez apporter une modification et la mettre en pratique de manière sûre et prévisible. Si vous avez peur d’apporter un changement parce que vous devez faire un jour ou deux de tests manuels sur celui-ci, vous pouvez vous demander ce que vous devez faire au niveau des processus ou des tests afin que vous puissiez effectuer cette modification en quelques minutes ou au pire pas plus d’une heure. Une stratégie consiste à implémenter l’intégration continue et la livraison continue, que nous aborderons dans le chapitre suivant.

Ressources

Pour plus d’informations sur les stratégies de création de branches, consultez les ressources suivantes :

Pour plus d’informations sur la façon de gérer les informations sensibles qui ne doivent pas être conservées dans les référentiels de contrôle de code source, consultez les ressources suivantes :

Pour plus d’informations sur les autres méthodes permettant de conserver des informations sensibles hors du contrôle de code source, consultez ASP.NET MVC : Conserver les paramètres privés hors du contrôle de code source.

PrécédentSuivant