[PYTHON] Si vous créez un programme qui démarre / arrête automatiquement l'environnement de vérification pour la demande d'extraction, la vérification a progressé.

Résumé de l'article

Je voulais pratiquer le développement avec GitHub Flow, c'est-à-dire le développement avec une simple opération de pull request, impliquant des ventes, et j'ai créé un tel environnement. À ce moment-là, j'ai créé et publié une application Web qui complète certaines fonctions manquantes, j'écrirai donc diverses histoires à ce sujet. (Il ne s'agit pas de savoir si vous pouvez réellement utiliser cette application Web, mais plutôt d'améliorer le développement avec un flux similaire.)

Référentiel d'applications Web

https://github.com/uniaim-event-team/pullre-kun

L'utilisation et les fonctions de cette application Web sont décrites dans README.md pour le moment, mais dans cet article, je les écrirai dans l'ordre, y compris quelques histoires de fond. Nous recherchons des éloges pour le support des problèmes et d'autres développements supplémentaires.

Contexte

Défis communs de développement

Jusqu'à présent, il y a eu les problèmes suivants dans le développement supplémentaire des applications Web existantes (services).

• Certaines fonctions n'ont pas été entièrement vérifiées. --Je n'ai pas été en mesure de donner une conférence suffisante sur la façon d'utiliser la fonction ajoutée / Elle n'est reconnue que par certaines personnes et devient une ** fonction cachée **
• Tout le monde oublie l'existence de la fonction au fil du temps et devient une ** fonction cachée ** ――En fait, le côté développement doit faire le travail de paramétrage des données qui peut être enregistré normalement si vous utilisez l'écran. ―― ~~ En premier lieu, les données ne peuvent pas être enregistrées à partir d'un écran normal ** La fonction cachée ** est créée et utilisée ~~

Introduction du flux GitHub (flux qui enrichit la partie externe)

Afin de résoudre de tels problèmes, nous avons considéré l'opération avec le flux suivant.

Par rapport à un flux de travail similaire typique, ce qui est un peu plus fort, c'est que le titulaire du ticket écrit même un scénario de test. Il y avait beaucoup de doutes à ce sujet, mais je pensais que ce serait possible si c'était techniquement possible ou impossible dans les points suivants, alors j'ai décidé de le prendre avec confiance.

―― Peu importe le montant d'un vendeur, lorsqu'il le fournit aux clients, l'explication minimale de fonctionnement de l'écran de gestion doit être possible sur demande. ――Il est plus naturel de confirmer qu'il peut être utilisé de manière satisfaisante par les utilisateurs finaux et d'autres utilisateurs du système sans aucune connaissance de la technologie. ――En ce qui concerne la liste des articles à confirmer à ce moment-là, même si le côté commercial n'a pas de point de vue tel que la couverture, il devrait être possible de simuler ce qui se fait réellement devant le client sans connaissances techniques. ..

Cependant, bien entendu, je pense qu'il est impossible pour la personne qui a émis les exigences / exigences de passer un test complet, donc s'il y en a un nécessaire, le côté développement l'augmentera. Il est difficile d'identifier le type de conditions dont dépend le système, quand les exigences / exigences sont émises, et il est difficile d'écrire un test qui les couvre d'un point de vue technique. J'ai décidé que c'était difficile.

Les défis de l'introduction du flux

Il y avait quelques problèmes techniques lors de l'introduction de ce flux, mais ils étaient généralement résumés dans les numéros suivants.

• Dans quel environnement le titulaire du ticket vérifie-t-il?

Par exemple, dans le cas d'une modification qui ajoute un élément dans une table, il est nécessaire de se référer au schéma défini dans la pull request. Il existe un moyen de tester dans l'environnement du développeur, mais comme le travail de développement du développeur se poursuit, on suppose souvent qu'il ne sera pas utilisable pendant le test. En outre, il est possible que cela ne fonctionne pas correctement en raison de l'influence d'une autre réparation, ce qui n'est pas bon pour l'autre. En premier lieu, il y a aussi le problème que tester avec une source qui contient d'autres modifications n'est pas un test pour le contenu de requête d'extraction pure.

Ensuite, lorsqu'il s'agit de créer manuellement un environnement de vérification pour celui-ci, il est un peu difficile de créer manuellement un environnement de vérification pour celui-ci à chaque fois dans une situation où une personne peut faire de nombreuses demandes d'extraction par jour.

Il y a quelque chose comme netlify si la modification ne peut être effectuée qu'avec JS, mais il y a beaucoup de problèmes dans la partie de la préparation du schéma et de l'ensemble de données, et dans le cas du projet cible, le côté serveur est Python, donc il n'a pas pu être appliqué pendant un certain temps.

Ne peut-il pas être résolu par docker?

En principe, cela peut être résolu avec docker, et il y a eu une histoire de faire la même chose avec docker il y a au moins trois ans! Mécanisme qui construit automatiquement l'environnement déployé avec l'ID de validation lors de l'émission d'une Pull Request pour faciliter la vérification au moment de la révision / avant la fusion

À l'origine, j'ai écrit un test automatique et cela fonctionnait avec CircleCI, donc cela fonctionne avec docker dans une certaine mesure, mais certains traitements ne fonctionnent pas bien simplement en créant un docker (en particulier, html est un pdf en utilisant wkhtml) En cours de conversion vers, je n'ai pas pu mettre immédiatement xvfb au milieu du processus sur le docker ... il ne fonctionne pas sur CircleCI), je vais faire un docker pour cela C'est ennuyeux et je suis là.

Ce que j'ai réellement fait

La politique est la suivante.

--Créez de nombreuses instances de vérification à l'avance, définissez l'équilibreur de charge et le DNS afin que vous puissiez y accéder normalement lorsque le processus serveur démarre, puis désactivez l'instance. --DB décide de partager Aurora ** y compris l'environnement de développement ** et de créer cette Aurora

• S'il y a une demande d'extraction, prenez-la et activez l'instance de vérification.
• Du côté de l'instance de vérification, identifiez le commit que l'instance doit extraire et démarrez le processus serveur avec ce commit.
• Éteignez le serveur de vérification correspondant lorsque la demande d'extraction est fermée

La partie qui traite la demande d'extraction à l'exclusion du travail préalable est la partie prise en charge par l'application Web.

L'image de configuration du système est la suivante. L'instance de contrôleur exécute l'application Web et les instances intermédiaires exécutent périodiquement un processus par lots pour lancer le processus serveur.

Constatations du fonctionnement réel

Cela ne fait que quelques semaines que j'ai commencé à fonctionner, et certaines parties sont différentes de l'état normal en raison de l'influence de la nouvelle couronne, mais pour le moment, je pensais que le test sur l'écran réel était devenu considérablement plus facile. En tant que vérificateur de développement, il est très facile pour moi de pouvoir vérifier ce que j'avais l'habitude de vérifier dans mon environnement, de corriger le schéma et de tester tout en faisant quelque chose, sans toucher du tout à mon environnement. De plus, je pense que c'est un grand pas en avant pour faciliter l'implication de non-développeurs avant la sortie.

Comment installer (configurer) une application Web

Ceci est identique à ce qui est décrit dans README.md. Traduction presque presque Google.

Créer une instance ec2

Créez une instance EC2. Et autorisez le port 5250 à l'un d'eux. L'une est appelée "instance de contrôleur". D'autres sont appelés "instances de mise en scène".

Créer des stratégies et des utilisateurs IAM

Créez une stratégie IAM qui autorise les actions suivantes:

「ec2：DescribeInstances」 「ec2：StartInstances」 「ec2：StopInstances」

La ressource de stratégie est l'instance que vous avez créée. (Remarque: la description des instances concerne toutes les ressources) Ensuite, attachez la stratégie à l'utilisateur / rôle et enregistrez les clés d'accès et secrètes.

Installer git

Installez git sur toute l'instance. Remarque: si vous utilisez amazon linux2

$ sudo yum install git

Configuration d'une application sur un serveur intermédiaire

Définissez l'application en tant que serveur intermédiaire.

Installez python3

Installez python3 sur toute l'instance. Remarque: si vous utilisez amazon linux2

$ sudo yum install python3

Installez mysql-client

Installez mysql-client sur toute l'instance. Remarque: si vous utilisez amazon linux2

$ sudo yum install mysql

Exécutez ou installez une base de données comme MySQL

Exécutez ou installez une base de données de type MySQL.

Un clone de pullre-kun

Clone Purle-kun.

install "requirements"

Installer les exigences (contenu de requirements.txt).

Exécutez get_basic_token.py

L'instance de contrôleur a une authentification de base. Vous devez créer un jeton de mot de passe (hachage) et l'enregistrer dans app.ini.

Créer un fichier app.ini

Créez un fichier app.ini. L'exemple est app.ini.default. Ensuite, déployez-le sur toute l'instance.

Modifier la crontab du serveur du contrôleur

Ajoutez la ligne suivante à la crontab de ** Controller Server **.

* * * * * cd /home/ec2-user/pullre-kun; python3 update_pull.py

Modifier le crontab du serveur intermédiaire

Ajoutez la ligne suivante aux crontabs sur ** Staging Server **.

* * * * * cd /home/ec2-user/pullre-kun; python3 client.py

Exécutez init.py

Exécutez la commande suivante sur le ** serveur de contrôleur **.

$ cd ~/pullre-kun
$ python3 init.py

Exécutez l'application pullre-kun

Exécutez la commande suivante sur le ** serveur de contrôleur **.

$ cd ~/pullre-kun
$ nohup python3 app.py＆

Enregistrer le serveur

Visitez https: // <votre-domaine> / serveur / liste pour voir l'ensemble du serveur. Cliquez ensuite sur le bouton Register Staging Server. Ensuite, allez dans https: // <votre-domaine> / master / server et mettez à jour le db_schema pour chaque enregistrement.

Enregistrer l'utilisateur

Allez dans https: // <votre-domaine> / master / git_hub_users et enregistrez vos utilisateurs. "Login" est le login de l'utilisateur github et db_schema est le schéma d'origine du clone.

Avec la procédure ci-dessus, s'il y a une demande d'extraction, l'environnement de vérification sera démarré automatiquement.

À propos des autres explications techniques

Dans l'ensemble, il s'agit de Flask + SQLAlchemy, mais il est configuré pour utiliser CherryPy comme serveur. S'il y a beaucoup d'espoir, je rédigerai peut-être bientôt un commentaire. (L'utilisation de WTForm à usage général qui correspond au modèle de SQL Alchemy est un peu spéciale) (Veuillez commenter cet article ou créer un problème sur GitHub et ajouter +1.)