how to automatically create a subdomain for every pull request

Question

Background

I got a team of untechnical QA's who have to do testing on iOS/android apps for every Pull Request (PR) that gets created by my backend team.

Question

This is what I want to do: everytime a backend engineer creates a PR on bitbucket, I would like a script to automatically deploy the code of that PR git branch into a subdomain of our dev server that matches the JIRA issue created.

For example suppose the jira issue that the PR addresses is BAC-421, then as soon as the engineer creates a PR, the script deploys the code they created into AWS EC2 so that the QA can point their apps to www.bac421.mydevdomain.com

What is the best way to do this? I'm a devops technical nube.

Update - Environment Specs

so here is a breakup of our env - the backend uses laravel 5.3 - it's deployed on AWS EC2 - we use forge for auto deployment (nothing fancy.. we just run this 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

that we run as soon as we merge dev unto master branch) - besides that we don't use any CI/CD tools although I'm open for recommendations - DNS provider is GoDaddy - our application server is nginx - our database is in a separate RDS instance

Answer 1

We do this at work.

We have a small server, let's call it the receiver, it's the target of the GitHub webhook events. It runs a small application that parses the payload and incorporates logic around how to proceed e.g. create a new server on the infrastructure provider, update the load balancer, deploy to an existing server, destroy the server etc. This could be a traditional web application serving up an API or it could be a serverless application, up to you how you want to approach it.

The receiver is relatively straightforward to handle, the other necessary supporting systems you'll need are an approach to configuration management/provisioning (how does the server have the packages necessary to run the application), secrets management (how does the server get access to sensitive information) and routing (how do the subdomains get updated and route to the correct server).

It could be worthwhile looking at preparing an AMI with the necessary services configured, a CloudFormation template with the infrastructure provisioning logic and CodeDeploy could handle deployments for you.

Configuration Management

This is really up to you and your team, there are a multitude of tools you can use or you can simply rely on shell scripting. At what point in the servers lifecycle you apply the changes is what's discussed in the AMI design article I linked.

Secrets Management

This is a challenging topic to address with the information at hand, in the interest of brevity I'll leave that up to you and your team.

Routing

There are a few ways you can handle routing, the Application Load Balancer (not to be confused with the ELB/NLB) offered by AWS supports host based routing. Alternatively you could use a reverse proxy like NGINX or HAProxy, when you provision a new environment you will need to update this routing (ideally automatically) irrespective of what approach you take.

Don't forget to consider how you'll handle the database/persistence layer & zero down time deployments. The question to ask with the persistence layer is whether the team will share a database and how that will interact with things like migrations. On the topic of zero downtime deployments, CodeDeploy should handle that nicely for you. One more thing, you mentioned a single mobile application pointing to different environments, how will you point these applications to the environments.

Answer 2

this setup worked perfectly for me using aws code deploy: