Target Audience: Beginner-intermediate friendly. I’ve included a number of helpful resources that offer more in depth explanations, scroll down to view those resources.

Quick overview of things to consider when piecing together architecture & selecting strategies:

• Application complexity
• Cost
• Expected Traffic (networking & hosting)
• Security
• Expected Release Cycles/Versioning
• For CI, how scalable is this tool: team size.
• Down Time tolerance
• How easy is this tool to work with?
• How easy is this tool to debug?
• How does this tool integrate together with other tools?
• How much customization do you want?

Quick CI/CD Overview

CI/CD stands for Continuous Integration/Continuous Deployment. It is essentially a structured and organized way to release changes to your application. This is important because it helps you manage the complexity of your application, while also controlling the impact that the changes you are carrying out have on the end-users.

Continuous Integration

There are various existing pre-defined implementations of continuous integration, regardless of the CI tool & workflow you choose, the end goal is to ensure that your web-application is in a workable state at all times, prior to deployment.

These are some things to consider:

• Application complexity
• Cost
• Security
• For CI, how scalable is this tool: team size.
• How easy is this tool to work with?
• How does this tool integrate together with other tools?
• How much customization do you want?

With these things in mind, here’s a quick overview of a few:

The two most popular CI tools listed on this table are: Jenkins & GitHub. So, here’s a quick comparison of the two: Jenkins offers more robust support for complex jobs and is highly customizable, whereas GitHub doesn’t have as much of a learning curve and integrates well with other tools. So, if you are just getting started with CI/CD, are working solo or on a really small team, GitHub may be the better choice.

Continuous Deployment:

Same idea, how do you release those changes in a controlled manner.

Here are some specifics to consider, when selecting your deployment strategy:

Risk tolerance

Downtime tolerance

Release frequencies

Here are a few existing Continuous Deployment strategies:

Blue green

2 identical environments, one of which is the testing environment and the other is the production environment. Once the testing environment has been thoroughly tested internally, and is good to go, traffic is routed onto the testing environment. The old production environment is kept as a stand-by in the case that an immediate rollback is needed. Flipping between the two environments as needed. This also helps avoid downtime. The drawback of this is that you have 2 separate environments to manage, so there is an additional layer of complexity to manage. This is also more expensive, because it requires more resources. This can be supported with AWS tools (Elastic load balancing, Route 53, AWS elastic beanstalk, and more)

Canary

Slowly rolls out the application, splitting traffic between the new and the old-stable version. This mitigates the downtime of the application, and any issues with deployment only affect a small subset of users at a time. This strategy is known for being cost efficient - no need for additional servers, because we are targeting a subset of users at a time. This strategy can be implemented with Kubernetes.

Rolling deployment

Slowly updating servers with new code changes, slowly allowing more and more users to have access to the newer version. So some servers have the updated application, and other servers have the stable/older version of the application. The drawback to this, is that rollback can be harder to achieve, and that releases may take longer. It is considered cost-effective because it does not require a duplicate environment. There are several ways to do this, one brute force way is to have multiple EC2 instances running, and slowly updating them with your recent changes.

How I remember:

Blue/green - switch between environments

Canary- changes target users

Rolling: changes target servers (same environment, one has changes and the other does not)

Hosting/Deployment Tools

Things to consider:

• Cost
• Security
• Expected traffic loads
• Mitigating Downtime - sometimes the issue is your domain name (I already ran into this, find a reliable provider)
• How easy is this to debug?

EC2

Simple brute force, it's essentially a VM that gets set up in accordance with the application needs. Local changes are then synced with the VM, the custom domain points to the VM’s IP (using Route 53). This is harder to debug, you pretty much just have the CLI to work with. It makes sense to have 2 instances running when you deploy changes, one with the older stable environment and one with the new changes, and just change the IP address that the domain name points to, so that rollback is easier. Testing is a little harder, when you only have 1 domain, it can get a little complicated pretty fast.

AWS LAMBDA

Slightly more complex setup, AWS lambda is an event based serverless compute resource. Basically an event triggers a function. It manages the server for you, whereas with an EC2 instance you have to do this manually. This integrates well with other services, enables different deployment strategies and can handle complexity. Cost: pay as you go. For a full-stack application the setup looks a little like this:

Frontend — static assets hosted on S3

Backend/API — Lambda functions exposed via Amazon API Gateway

Domain — Route 53 pointing to your application

Drawbacks:

• there may be a delay, or cold starts with your application.
• There is an execution time limit (15 mins)
• Storage limitations

Vercel

Pretty easy to get started, integrates automatically with GitHub. Fastest. Might not be able to handle more complex deployment strategies. This connects with a specific branch on your GitHub, so you may be able to implement deployment strategies with GitHub actions. This can support your full stack application well. A huge strength is that this offers an intuitive UI and dashboard, also allows you to purchase a domain name.

Brief honorable mentions:

Code pipeline

Pricey, can easily integrate CI/CD practices but requires additional services to handle more robust applications. Uses more resources, so it can get pricey fast.

Aws beanstalk

Integrates well with the AWS ecosystem, can handle robust logic. Use case for this are applications that are not mission critical. The strength is that it handles a lot of the complex logic for you, and your server. There are plenty of tutorials available.

Resources:

CI/CD overview: https://blog.jetbrains.com/teamcity/2026/03/best-ci-tools/#custom-ci-cd-tools

Deployment: https://launchdarkly.com/blog/deployment-strategies/

Hosting/deployment:

• https://www.geeksforgeeks.org/devops/difference-between-lambda-and-amplify-in-aws/
• https://aws.amazon.com/amplify/hosting/
• https://youtu.be/lY7JWAvUkcE?si=nSTS3Ot4YJ9rHXnt
• https://kevinkiruri.medium.com/serverless-web-app-development-made-easy-a-complete-guide-with-aws-amplify-dynamodb-lambda-and-052daf5b978d

Github limits: https://docs.github.com/en/actions/reference/limits

Github Vulnerabilities:

• https://arctiq.com/blog/top-10-github-actions-security-pitfalls-the-ultimate-guide-to-bulletproof-workflows#:~:text=According%20to%20Wiz%2C%20only%203.9,version%20of%20the%20compromised%20action.

Github Vs Jenkins overview:

• https://dev.to/ekirigwe/securing-cicd-pipelines-github-actions-vs-jenkins-1p2e

Github Vs CodePipeline:

• https://www.cloudoptimo.com/blog/github-actions-vs-aws-codepipeline-a-comprehensive-comparison/

bitBucket Pipeline:

• https://www.atlassian.com/software/bitbucket/features/pipelines

CD overview: https://launchdarkly.com/blog/deployment-strategies/

Blue green deep dive: https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment

Deployment strategies comparison: https://denverd1301.medium.com/blue-green-vs-canary-vs-rolling-deployments-c67f4ea0a527

Canary deployment: https://youtu.be/LD8pTFHS8io?si=VhzEQbohE7k602t_

AWS Lamda:

• https://medium.com/aws-serverless-microservices-with-patterns-best/aws-lambda-and-how-aws-lambda-works-c0116d383eeb
• https://medium.com/@srushtithakare594/getting-started-with-aws-lambda-a-beginner-friendly-guide-096949ae9bf3