Skip to content
Noback

CI/CD

Continuous Integration and Continuous Deployment (CI/CD) streamline the development process by automatically testing, building, and deploying your applications and infrastructure. Our system employs AWS Serverless Application Model (SAM) to deploy both infrastructure and application code simultaneously, ensuring consistency and reducing deployment complexity.

Infrastructure and Code Deployment (IcD)

The CI/CD pipeline leverages AWS SAM, built on AWS CloudFormation, to manage applications and their associated resources:

  • Infrastructure as Code (IaC): Define your AWS resources alongside your application code in SAM templates.
  • Automated Deployment: Automatically package and deploy infrastructure and application code in a single, repeatable process.

This process could be executed n times from a single repository.

Automated SAM Script

While developing, there is an automated script that represents the whole deployment process:

Terminal window
export...
export...
export...


./deploy.sh

It does verifications, build the SAM template dinamically for a given environemnt, it wraps the layer with the lambdas and deploys everything.

Integrating with GitHub Actions

The best scenario for collaborative environemnts is to deploy automatically every time you push to a specific branch, allowing you to have multiple branchs for multiple accounts and allows more complex pipelines and more automatization?¿?¿?.

To avoid creating IAM users with fixed access keys, we encourage to use a OIDC relation between IAM and Github, to give github the exact permission it needs to perform the task at hand.

Step 1: OIDC relation with IAM

Now we have to set some permissions to Github in order to be able to create infrastructure and resources. The basic demo is configured with a set of ------ 🔴

🔴🔴 can we set the part on AWS from SAM??? 🔴🔴 🔴🔴 and then explain how to set it up (it may be enough with part ) 🔴🔴

Step 2: Create a Workflow File

  • In your repository, create .github/workflows/deploy.yml with the following basic structure:
name: Deploy to AWS


on:
  push:
    branches:
      - main


jobs:
  deploy:
    runs-on: ubuntu-latest


    steps:
      - name: Checkout code
        uses: actions/checkout@v4


      - name: Set up AWS SAM CLI
        uses: aws-actions/setup-sam@v2


      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1


      - name: SAM Build
        run: sam build


      - name: SAM Deploy
        run: |
          sam deploy --no-confirm-changeset --no-fail-on-empty-changeset --stack-name your-stack-name --capabilities CAPABILITY_IAM

Step 3: Setting secrets and variables

To securely manage sensitive data:

  • Navigate to your repository’s Settings > Secrets and variables > Actions.
  • Create new repository secrets:
    • AWS_REGION
    • S3____

These secrets securely provide AWS credentials required by GitHub Actions to access your AWS resources without exposing sensitive information in your repository.

By setting up your CI/CD pipeline this way, your infrastructure and application code deployment become fully automated, secure, and easily manageable.

From here, it could be more than enough for a lot of projects, but automation on pipelines could you get further if required. Integrating linters, prettiers, or other processes its generally convenient, and it may be a good idea to use trunk base development, and build some logic to control how you get to production accoring to project requiements, but these topics are beyond the scope of the project.