https://github.com/epomatti/quickstart-cicd

Simple CI/CD release method
https://github.com/epomatti/quickstart-cicd

aws aws-ecr cicd docker ecr github-actions go

Last synced: 9 days ago
JSON representation

Simple CI/CD release method

• Host: GitHub
• URL: https://github.com/epomatti/quickstart-cicd
• Owner: epomatti
• License: mit
• Created: 2023-06-07T00:31:26.000Z (over 1 year ago)
• Default Branch: main
• Last Pushed: 2023-06-11T16:08:37.000Z (over 1 year ago)
• Last Synced: 2024-11-17T00:23:28.612Z (2 months ago)
• Topics: aws, aws-ecr, cicd, docker, ecr, github-actions, go
• Language: Dockerfile
• Homepage:
• Size: 13.7 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# Quick-starter CI/CD

A quick-starter CI/CD strategy for simple projects with a modest collection of good practices that every team can implement.

To run the example, create your ECR and set up the required credentials:

```sh

aws ecr create-repository --repository-name "myapp/api"

```

### Non-Production releases

Once the code is ready for live integration testing, create and push your tag:

> ℹ️ If you don't need dynamic environments with IaC and paired branches, choose a centralized integration branch from which you'll generate your tags.

```sh

# You can also create tags

git tag -a v1.2.3 -m ""

git push --tags

```

Have a workflow ready to build, such as this example in the [release-dev.yml](/.github/workflows/release-dev.yml) example:

```yaml

on:

  push:

    tags:

      - 'v*.*.*'

```

If you want to automate the deployment as well and you're using docker images, have your workflow to push the images with both tags:

- `latest`

- `v1.2.3`

Your code hosting service should have a webhook, or automatically integrate with the repository to trigger the deployment.

```sh

docker build -t $ECR_IMAGE:latest -t $ECR_IMAGE:$GITHUB_REF_NAME .

docker push $ECR_IMAGE:latest

docker push $ECR_IMAGE:$GITHUB_REF_NAME

```

> 💡 Always have separated image repositories from production - you'll run into security and reliability issues if you share a repository between environments.

### Production releases

You should re-use your existing tags for production releases.

On GitHub you can use [release][1] feature. Alternatively, there's the CLI:

```sh

gh release create "v1.2.3" --verify-tag --notes "New features" 

```

Have a workflow to respond for such as in the [release-prod.yml](/.github/workflows/release-prod.yml):

```yaml

on:

  release:

    types: [published]

```

Usually, it is a good idea to manually deploy the new container image, so do not use `latest` images in production. Rather, opt to use tag versions `v1.2.3` only.

### Code continuous build

For continuous integration, create a simple code build that will trigger for pushes and PRs.

[1]: https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository