Contexte

J'ai une équipe d'AQ non techniques qui doivent faire des tests sur les applications iOS / Android pour chaque Pull Request (PR) créée par mon équipe backend.

Question

C'est ce que je veux faire: chaque fois qu'un ingénieur backend crée un PR sur bitbucket, j'aimerais qu'un script déploie automatiquement le code de cette branche PR git dans un sous-domaine de notre serveur de développement qui correspond au problème JIRA créé.

Par exemple, supposons que le problème jira que les adresses PR soient BAC-421, puis dès que l'ingénieur crée un PR, le script déploie le code qu'ils ont créé dans AWS EC2 afin que le QA puisse pointer leurs applications vers www.bac421.mydevdomain. com

Quelle est la meilleure façon de procéder? Je suis un technicien devops.

Mise à jour - Spécifications d'environnement

voici donc une rupture de notre env - le backend utilise laravel 5.3 - il est déployé sur AWS EC2 - nous utilisons forge pour le déploiement automatique (rien de spécial .. nous exécutons simplement ce script:

cd /home/forge/default
git fetch --tags 
git pull origin master
git describe
composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader
echo "" | sudo -S service php7.1-fpm reload

if [ -f artisan ]
then
    php artisan migrate --force
    php artisan config:cache
    php artisan queue:restart
fi

que nous exécutons dès que nous fusionnons dev vers la branche principale) - en plus de cela, nous n'utilisons aucun outil CI / CD bien que je sois ouvert aux recommandations - le fournisseur DNS est GoDaddy - notre serveur d'applications est nginx - notre base de données est dans un instance RDS distincte

Nous le faisons au travail.

Nous avons un petit serveur, appelons-le le récepteur, c'est la cible des événements de webhook GitHub . Il exécute une petite application qui analyse la charge utile et intègre une logique sur la façon de procéder, par exemple créer un nouveau serveur sur le fournisseur d'infrastructure, mettre à jour l'équilibreur de charge, déployer sur un serveur existant, détruire le serveur, etc. Il pourrait s'agir d'une application Web traditionnelle servant une API ou il peut s'agir d'une application sans serveur, à vous de voir comment vous souhaitez l'aborder.

Le récepteur est relativement simple à gérer, les autres systèmes de support nécessaires dont vous aurez besoin sont une approche de la gestion / provisioning de la configuration (comment le serveur dispose-t-il des packages nécessaires pour exécuter l'application), la gestion des secrets (comment le serveur accède-t-il à informations sensibles) et le routage (comment les sous-domaines sont-ils mis à jour et acheminés vers le serveur approprié).

Il pourrait être utile d'envisager de préparer une AMI avec les services nécessaires configurés, un modèle CloudFormation avec la logique de provisionnement d'infrastructure et CodeDeploy pourrait gérer les déploiements pour vous.

Gestion de la configuration

Cela dépend vraiment de vous et de votre équipe, il existe une multitude d'outils que vous pouvez utiliser ou vous pouvez simplement compter sur des scripts shell. À quel stade du cycle de vie des serveurs vous appliquez les modifications est ce qui est discuté dans l' article de conception AMI que j'ai lié.

Gestion des secrets

C'est un sujet difficile à aborder avec les informations à portée de main, dans un souci de concision, je laisse cela à vous et à votre équipe.

Acheminement

Il existe plusieurs façons de gérer le routage, l'Application Load Balancer (à ne pas confondre avec ELB / NLB) proposé par AWS prend en charge le routage basé sur l'hôte . Vous pouvez également utiliser un proxy inverse comme NGINX ou HAProxy, lorsque vous provisionnez un nouvel environnement, vous devrez mettre à jour ce routage (idéalement automatiquement) quelle que soit l'approche que vous adoptez.

N'oubliez pas de considérer comment vous allez gérer la base de données / couche de persistance et les déploiements sans temps d'arrêt. La question à poser avec la couche de persistance est de savoir si l'équipe partagera une base de données et comment cela va interagir avec des choses comme les migrations. Sur le sujet des déploiements sans interruption de service, CodeDeploy devrait gérer cela bien pour vous. Encore une chose, vous avez mentionné une seule application mobile pointant vers différents environnements, comment allez-vous pointer ces applications vers les environnements.

cette configuration a parfaitement fonctionné pour moi en utilisant le déploiement de code aws: