Documenter le déploiement d’une application dynamique web ou web mobile Flashcards
Pourquoi ne pas développer directement sur la main ? pourquoi s’enquiquiner avec plusieurs branches (une branche par fonctionnalité, une branche dev, …) avant de merger le code final dans la branche main ?
Bien que cela puisse sembler fastidieux d’avoir un enchainement de plusieurs branches distinctes, cette approche est une pratique de développement saine qui favorise la collaboration, la stabilité et la gestion efficace du code source.
En détail, cela permet par exemple :
- d’éviter que les développeurs(ses) ne se marchent dessus lorsqu’ils travaillent sur une même application. Une branche par fonctionnalité permet d’organiser le travail en équipe de manière plus efficace
- d’exécuter des linters et des tests automatiques à plusieurs étapes avant que le code n’arrive sur la branche finale “main”
Comment avez vous géré les configurations de votre application en fonction de l’environnement dans lequel se trouve votre application ?
Les configurations par environnement sont inscrites dans des fichiers .env dédiés. Nous avons un fichier principal .env (ou .env.sample) qui contient toutes les configurations à paramétrer. Par exemple, en local lorsque je travaillais, je recopiais le fichier .env en un nouveau fichier .env.local , et c’est dans le fichier .env.local que je renseignais par exemple les informations permettant à mon application backend de se connecter à la base de données (adresse de la BDD, nom d’utilisateur, mot de passe, …)
Pouvez vous expliquer dans les grandes lignes le workflow que vous avez utilisé lorsque vous avez travaillé en groupe ? plus précisemment, vous êtes affecté sur l’implémentation d’une fonctionnalité ; que se passe-t’il en dehors de l’écriture du code de la fonctionnalité ?
Pas de réponse type ici : le but est de savoir expliciter l’organisation qui a été mise en place durant le développement d’un projet (idéalement) fait en équipe.
Parlez des différentes branches qui ont été utilisées (et pourquoi), parlez des vérifications qui sont automatiquement jouées lorsque le code est mergé sur une branche (exécution des linters, exécutions des tests automatiques si vous en avez défini, …). Parlez également de la review de code qui a été mise en place durant le projet.
Si vous avez déployé votre application sur un serveur ou VPS dédié, c’est également le bon moment pour le mettre en avant et en parler (les difficultés rencontrées, les choix que vous avez faits, etc…)
C’est quoi un environnement de production ?
L’environnement de production est l’environnement sur lequel est déployée (sur un serveur physique par exemple) mon application qui sera utilisée par les utilisateurs finaux.
Dans le cadre du cycle de vie du développement d’une application, que désigne le terme CI/CD (Continious Delivery) ?
Le terme CI (Continuous Integration - intégration continue) désigne la pratique consistant à fusionner régulièrement le code développé par les différents membres d’une équipe dans un référentiel partagé (un repository github par exemple). À chaque fusion, des processus peuvent être déclenchés pour vérifier si le code ne comporte pas d’erreur (linters, tests automatiques, …). Une intégration continue a été effectuée tout au long du projet 3 par exemple.
Le terme CD (Continuous Delivery - livraison continue) se concentre sur la garantie que le logiciel est toujours prêt à être déployé sur un environnement (environnement pour les tests d’intégration, environnement de production, …) avec une approbation manuelle.
Dans le cadre du cycle de vie du développement d’une application, que désigne le terme CD (Continious Deployement) ?
Dans le cadre du cycle de vie du développement d’une application, le terme CD (Continuous Deployment - déploiement continu) désigne une extension de la pratique de Continuous Delivery.
Tandis que la livraison continue nécessite dans son processus une approbation manuelle par l’équipe pour déployer l’application, le déploiement continu automatise complètement le déploiement de l’application sans qu’aucune approbation manuelle soit nécessaire. Cela fluidifie encore plus le cycle de vie d’un projet, le risque cependant est de déployer par mégarde des bugs non détectés en production. Le déploiement continue exige alors la mise en place de pipelines de tests, de qualification du code très robuste.
Quels sont les acronymes de CI/CD ?
CI : Continious Integration
CD : Continious Delivery
Dans un repo git, dans quel fichier est-il opportun de décrire les instructions à suivre pour déployer le projet ? (en local par exemple, pour pouvoir développer dessus)
Dans le fichier README.md situé à la racine du projet
Vous avez utilisé un gestionnaire de package dans votre projet, dans quel fichier peut on voir quels packages externes ont été installés dans votre projet ?
cas projet nodejs : le fichier package.json
cas projet php : composer.json
Avez vous utlisé un gestionnaire de package côté backend ?
cas projet nodejs : npm
cas projet php : composer
Pouvez vous expliquer en quelques mots ce qu’est docker et en quoi cette technologie facilite la mise en place de CI/CD dans un projet ?
Docker est une technologie qui permet de créer, à l’aide de simples fichiers de configuration, des systèmes d’exploitations virtuels pré-configurés permettant de démarrer l’application du projet. Cela s’avère très pratique déjà au sein d’une équipe de développeurs car il n’est plus nécessaire de configurer péniblement chacun des ordinateurs pour pouvoir travailler/développer sur le projet. Dans le cadre de la CI/CD, docker devient un incontournable aujourd’hui dans la mesure où cette technologie permet de déployer automatiquement l’application dans des environnements différents tout au long du cycle de vie du projet. Déployer facilement et automatiquement l’application facilite grandement alors l’exécution de linters et/ou tests automatiques dans les différents environnements (envonnement d’intégration, environnement de pré-production, …) du projet.
Pouvez vous expliquer dans les grandes lignes en quoi consiste le métier de DevOps ?
Dans le cycle de vie d’un projet, il existe le concept appelé “lead time” (délais de livraison) : cela désigne le temps écoulé entre le moment où un développeur commit/push son code et le moment où ce code est déployé en production.
Un des principaux objectifs d’un DevOps est de réduire le “lead time” global en mettant en place des processus qui font automatiquement passer le code d’un environnement à l’autre jusqu’à la production (par ex : environnement d’intégration -> environnement de pré-production -> environnement de production).
Dans les processus mises en place par le DevOps entre les différents environnements, des outils de vérification de la qualité du code (linter) et/ou des tests automatiques sont ajoutés afin d’assurer la qualité minimale attendue du projet.
Je veux héberger mon site en ligne, j’ai le choix entre utiliser un serveur dédié et un VPS. Quels sont les grandes différences entre les deux ?
Louer un serveur dédié consiste, comme son nom l’indique, à louer un serveur physique entier (pour héberger par exemple son site Web). Cela peut couter relativement cher (quelques centaines à milliers d’euros voir plus, par mois) et peut alors être tout à fait inadapté pour les petits projets et sites web courants. La location de serveur dédié s’adresse alors surtout aux projets de grandes envergures. Un VPS (virtual private serveur) est un serveur virtuel hébergé dans un serveur physique ; un serveur physique pouvant gérer une multitude de serveurs virtuels, le coût d’un VPS est alors beaucoup plus faible (à partir de ~3 euros par mois, le prix évolue en fonction de la puissance utilisée prévue pour le VPS).
C’est quoi Docker ? en quoi cet outil peut être pratique pendant le déveppelement d’un projet ?
Docker est un outil permettant de créer des OS virtuels. Cela peut être très pratique car il n’est alors plus nécessaire de configurer à la main tous les ordinateurs des développeurs (instlalation de la bonne version de node, de composer, …). Il suffit de démarrer un container Docker depuis une image Docker pré-configurer pour démarrer un OS virtuel dans sa machine qui contient toutes les configurations requises pour pouvoir développer son projet
