sfondo

Ho un team di QA non tecnici che devono eseguire test su app iOS / Android per ogni richiesta pull (PR) che viene creata dal mio team di backend.

Domanda

Questo è quello che voglio fare: ogni volta che un ingegnere di backend crea un PR su bitbucket, vorrei uno script per distribuire automaticamente il codice di quel ramo git di PR in un sottodominio del nostro server di sviluppo che corrisponde al problema JIRA creato.

Ad esempio, supponiamo che il problema di jira sia che gli indirizzi PR sono BAC-421, quindi non appena l'ingegnere crea un PR, lo script distribuisce il codice che hanno creato in AWS EC2 in modo che il QA possa indirizzare le loro app a www.bac421.mydevdomain. com

Qual è il modo migliore per farlo? Sono una nuvola tecnica devops.

Aggiornamento - Specifiche ambientali

quindi ecco una rottura del nostro env - il backend usa laravel 5.3 - è distribuito su AWS EC2 - usiamo forge per la distribuzione automatica (niente di speciale .. abbiamo appena eseguito questo 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

che eseguiamo non appena uniamo dev al ramo principale) - oltre a ciò non usiamo alcun strumento CI / CD anche se sono aperto per consigli - Il provider DNS è GoDaddy - Il nostro server delle applicazioni è nginx - Il nostro database è in un istanza RDS separata

Lo facciamo al lavoro.

Abbiamo un piccolo server, chiamiamolo il ricevitore, è l'obiettivo degli eventi webhook di GitHub . Esegue una piccola applicazione che analizza il payload e incorpora la logica su come procedere, ad esempio creare un nuovo server sul provider dell'infrastruttura, aggiornare il bilanciamento del carico, distribuire su un server esistente, distruggere il server ecc. Potrebbe trattarsi di una tradizionale applicazione web un'API o potrebbe essere un'applicazione senza server, a te come vuoi affrontarla.

Il ricevitore è relativamente semplice da gestire, gli altri sistemi di supporto necessari che ti serviranno sono un approccio alla gestione / provisioning della configurazione (come fa il server a disporre dei pacchetti necessari per eseguire l'applicazione), la gestione dei segreti (come accede al server informazioni sensibili) e il routing (in che modo i sottodomini vengono aggiornati e instradati al server corretto).

Potrebbe essere utile guardare alla preparazione di un AMI con i servizi necessari configurati, un modello CloudFormation con la logica di provisioning dell'infrastruttura e CodeDeploy potrebbe gestire le implementazioni per te.

Gestione della configurazione

Questo dipende davvero da te e dal tuo team, ci sono una moltitudine di strumenti che puoi usare o puoi semplicemente fare affidamento sullo scripting della shell. A che punto del ciclo di vita dei server si applicano le modifiche è ciò che è discusso nell'articolo di progettazione AMI che ho collegato.

Gestione dei segreti

Questo è un argomento impegnativo da affrontare con le informazioni a portata di mano, nell'interesse della brevità lo lascerò a te e al tuo team.

Routing

Esistono diversi modi per gestire il routing, Application Load Balancer (da non confondere con ELB / NLB) offerto da AWS supporta il routing basato su host . In alternativa, è possibile utilizzare un proxy inverso come NGINX o HAProxy, quando si effettua il provisioning di un nuovo ambiente, sarà necessario aggiornare questo instradamento (idealmente automaticamente) indipendentemente dall'approccio adottato.

Non dimenticare di considerare come gestirai il database / livello di persistenza e zero tempi di inattività. La domanda da porsi con il livello di persistenza è se il team condividerà un database e in che modo interagirà con cose come le migrazioni. Per quanto riguarda le distribuzioni zero dei tempi di inattività, CodeDeploy dovrebbe gestirlo in modo ottimale. Ancora una cosa, hai menzionato una singola applicazione mobile che punta a diversi ambienti, come indicherai queste applicazioni agli ambienti.

questa configurazione ha funzionato perfettamente per me usando aws code deploy: