https://github.com/salimkayabasi/example-github-flow-deployment

example repo for GHA and GitHub Flow
https://github.com/salimkayabasi/example-github-flow-deployment

Last synced: 7 days ago
JSON representation

example repo for GHA and GitHub Flow

• Host: GitHub
• URL: https://github.com/salimkayabasi/example-github-flow-deployment
• Owner: salimkayabasi
• Created: 2021-08-23T08:14:28.000Z (about 3 years ago)
• Default Branch: main
• Last Pushed: 2021-08-23T15:27:20.000Z (about 3 years ago)
• Last Synced: 2024-04-10T13:58:47.837Z (7 months ago)
• Homepage:
• Size: 665 KB
• Stars: 2
• Watchers: 2
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# example-github-flow-deployment

Most of the software companies are using `git` as version control system. There are several ways of working with `git`.

Initial purpose of having version control system for the codebase was having an identical and manageable code sharing

between team members.

Nowadays, that is not enough for modern applications. We also need to consider testability, easy to deploy, and

supporting multiple environments.

With this repo, I'll setup a basic demo for GitHub Flow + GitHub Actions

## Steps

Start with protecting your `main` branch.

![branch protection](./assets/branch-protection.png)

Create a CI file under `.github/workflows` folder and `.yml` file with any name. I've started with hello-world example

from `GitHub`.

Later on we need to set our triggers; We need a manual trigger for enabling us to choose any branch and set target to be

deployed.

```yaml

on:

  workflow_dispatch:

    inputs:

      environment:

        description: 'Name of environment to deploy'

        required: true

        default: 'Staging'

```

After merging these changes to `main` branch, we can trigger the pipeline with using any branch and target env name.

![manual triggers](./assets/manual-triggers.png)

Let's run it against `Staging` env. Default value of ENVIRONMENT was `Develop` but it should be overridden as `Staging`.

![setting new env name](./assets/setting-new-env-name.png)

![echo env name](./assets/echo-env-name.png)

This flow creates ENVs automagically for us! Same goes for other ENVs once we created them.

![env list](./assets/env-list.png)

## Advanced Features

So far, it was only for enabling us to have Cont. Development flow with multiple ENVs. What if we would like to have

more control on what is being deployed and even setting more protections on flow.

### ENV specific secrets

GitHub Secrets can be defined as level of `Organization`, `Repository` or even `Environment`.

![repo secret](./assets/secrets-repo.png)

## Some good articles

* https://nvie.com/posts/a-successful-git-branching-model/

* https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf

* https://softwareengineering.stackexchange.com/questions/263164/why-squash-git-commits-for-pull-requests

* http://scottchacon.com/2011/08/31/github-flow.html

* https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy

* https://salimkayabasi.com/blog/2021/05/better-github-flow-with-using-github-actions/