Skip to main content
remove noise
Source Link
Pierre.Vriens
  • 7.2k
  • 14
  • 37
  • 84

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 nginxNGINX 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.

Hopefully I've been of some help, good luck.

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.

Hopefully I've been of some help, good luck.

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.

Added supporting links in line with OPs request plus some formatting,
Source Link

We do this at work.

We have a small server, let's call it the receiver, it's the target of the GitHub webhook eventsGitHub 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 AMIAMI with the necessary services configured, a cloudformationCloudFormation template with the infrastructure provisioning logic and AWS code deployCodeDeploy 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.

Hopefully I've been of some help, good luck.

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, destroy the server etc.

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 AWS code deploy could handle deployments for you.

Don't forget to consider how you'll handle the database/persistence layer & zero down time deployments.

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.

Hopefully I've been of some help, good luck.

Source Link

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, destroy the server etc.

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 AWS code deploy could handle deployments for you.

Don't forget to consider how you'll handle the database/persistence layer & zero down time deployments.