// 에드센스


1. 로컬에서 브랜치명 변경하기

 

git branch -m oldname newname

 

git branch -m [기존브랜치이름] [새로운브랜치이름]

간단하다.

 

 

 

 


2. 원격저장소의 브랜치명까지 변경하기

 

로컬저장소에서는 브랜치 이름이 변경되었다.

이어서 이 변경사항을 원격저장소에도 반영해보자.

 

현재 로컬저장소는 newname이지만 원격저장소는 oldname이다

 

 

 

 

아까 로컬에서의 git branch -m옵션으로 oldname브랜치의 이름을 newname으로 바꿨기에

이 사항을 원격저장소에 push한다.

 

git push origin :oldname

 

이전 이름인 oldname 앞에 콜론(:)을 붙혀서 oldname 브랜치의 삭제사항을 푸시하는 것이다.

그러면

요렇게 나오면서 

 

 

 

원격저장소에 있던 oldname 브랜치가 사라진다.

 

 

 

 

 

이제 이름을 바꾼 브랜치를 푸시하면 된다.

git push --set-upstream origin newname

그러면 이렇게 나오면서

 

 

 

원격저장소에도 수정된 이름의 브랜치가 잘 반영됨을 확인할 수 있다.

 

 

 

 

꿀팁 한 가지.

변경내용이 없어도 커밋을 하고싶다면

git commit --allow-empty -m "Empty Commit Message"

하면 된다 !

 

 

 

 

참고:

 

 

'Git' 카테고리의 다른 글

[Git] Branch 이름 변경하기  (0) 2022.04.26
[Git] git stash  (0) 2021.11.24
[Git] Branch와 Merge  (0) 2021.08.14
[Git] BFG Repo-Cleaner를 사용한 민감한 히스토리 삭제  (0) 2021.08.14
[Git] git bash를 사용한 버전관리 시작하기  (0) 2021.08.13


1. Github Actions를 구성하는 요소

너무 잘 정리하신분의 글을 퍼왔다.

 

  • 1) Workflow
    • 여러 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스
    • 최상위 개념
    • Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장됨
  • 2) Event
    • Workflow를 Trigger(실행)하는 특정 활동이나 규칙
    • 예를 들어 다음과 같은 상황을 사용할 수 있음
      • 특정 브랜치로 Push하거나
      • 특정 브랜치로 Pull Request하거나
      • 특정 시간대에 반복(Cron)
      • Webhook을 사용해 외부 이벤트를 통해 실행
    • 자세한 내용은 Events that trigger workflows 참고
  • 3) Job
    • Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행됨
    • 다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능함
  • 4) Step
    • Task들의 집합으로, 커맨드를 날리거나 action을 실행할 수 있음
  • 5) Action
    • Workflow의 가장 작은 블럭(smallest portable building block)
    • Job을 만들기 위해 Step들을 연결할 수 있음
    • 재사용이 가능한 컴포넌트
    • 개인적으로 만든 Action을 사용할 수도 있고, Marketplace에 있는 공용 Action을 사용할 수도 있음
  • 6) Runner
    • Gitbub Action Runner 어플리케이션이 설치된 머신으로, Workflow가 실행될 인스턴스
    • Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner로 나뉨
    • Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB

 

참고:

 

 

 

 


2. Beanstalk으로 배포하기

프로젝트 최상위에 .github/worfklows 폴더를 만들고 그 안에 .yml 스크립트로 깃헙 액션의 동작을 지정할 수 있다.

yml 파일 대부분은 처음 보더라도 대충 어떤 의미인지 알 수 있다.

 

name: Backend CI/CD

on:
  push:
    branches: [ develop ]

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      # Download AWS CLI 2
      - name: Install AWS CLI 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          which aws
          sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
          
      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # npm install for ci
      - run: npm ci

      # Build
      - run: npm run build

      # Unit test
      - run: npm run test:unit

  deploy:
    name: BeanStalk Deploy
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['14.x']
    needs: build
    steps:
      - uses: actions/checkout@v2

      # Initialize Node.js
      - name: Install Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      # Install project dependencies
      - name: Install dependencies
        run: npm install

      # Download AWS CLI 2
      - name: Install AWS CLI 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          which aws
          sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # Build
      - name: Run build
        run: npm run build

      # Make upload zip file
      - name: Generate deployment package
        run: zip -r deploy.zip . -x '*.git*' './aws/*' './node_modules/*' './dist/*' awscliv2.zip

      # Deploy to Elastic Beanstalk
      - name: Deploy to EB
        uses: einaregilsson/beanstalk-deploy@v18
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: ${{ secrets.APPLICATION_NAME }}
          environment_name: ${{ secrets.ENVIRONMENT_NAME }}
          region: ${{ secrets.AWS_REGION }}
          version_label: ${{github.SHA}}

위에서부터 살피며 내려가자

 

 

 

 

on

jobs를 실행시킬 트리거를 지정한다. 위의 코드처럼하면 develop 브랜치에 push가 발생했을때 github actions가 실행된다는 의미다.

다음처럼 여러개의 트리거를 지정할 수 있다.

  on:
    push:
      branches: [ master ]
    pull_request:
      branches: [ master ]

 

 

 

 

jobs

jobs는 Build와 Deploy로 구성된다. 그리고 각각 name을 지정한 것을 볼 수 있다.

 

 

 

 

Configure AWS Credentials

      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

코드 내부에 aws를 사용한 부분이 다수 존재하기에 runner에 aws cli를 설치해 주어야한다.

${{ secrets.블라블라 }}

이 부분은 깃허브 - Settings - Secrets 탭에서 Name-Value를 지정할 수 있다.

 

 

${{ secrets.블라블라 }} 에서 블라블라에 Name을 입력해주면 대응되는 Value를 사용할 수 있다.

 

 

 

 

npm ci

이거는 npm install과 같은 역할이다.

다만,

ci 과정에서 쓰는 install이다.

거의 두배 이상 빠른 속도를 보여준다.

 

npm install은 package.json 내부의 dependencies와 devDependencies를 기준으로 패키지 파일을 설치하는 반면

npm ci는 package-lock.json의 lockfile을 기준으로 패키지를 설치한다.

 

이렇게 되면 package.json내의 파일과 package-lock.json 내의 버전 등이 다를 경우,

package-lock.json을 기준으로 package.json 파일을 수정하며, 명시되지 않은 부분에서는 오류를 발생시키므로 Application 관리에 있어서 안정성을 확보할 수 있다.

 

 

 

 

npm run build

# Build
- run: npm run build

package.json에 build 스크립트를 실행한다.

이때 한가지 사용한것이 

 

 

npm install concurrently --save

이거다.

 

 

 

빌드시 .env파일을 비롯한 여러 설정파일들이 존재해야하는데,

이런 중요파일들은 S3에서 다운로드해야만 한다.

따라서 build 스크립트 이전에 수행되는 prebuild스크립트에서 중요 파일들을 미리 다운 받는 행동을 먼저 해야한다.

 

그런데 중요 파일들이 2개 이상일 경우 prebuild 안에서 동시에 스크립트가 수행될 수 있도록 해주는 concurrently를 사용했다.

 

"scripts": {
	...
    "prebuild": "concurrently \"aws s3 cp s3://blahblah .env\" \"aws s3 cp s3://blahblah somethingimportant.json \"",
    "build": "tsc",
    ...
  },

이렇게 concurrently 키워드를 쓰고 ""로 묶어서 스크립트를 넣어주면 된다.

 

 

 

 

deploy - Make upload zip file

# Make upload zip file
- name: Generate deployment package
  run: zip -r deploy.zip . -x '*.git*' './aws/*' './node_modules/*' './dist/*' awscliv2.zip

Beanstalk에 올리기위한 zip 파일을 생성한다.

zip 명령어로 압축파일을 생성하고 다음 step에서 S3로 업로드하고, Beanstalk에 배포된다.

 

 

이때, 압축파일에 포함시키지 않을 파일들을 -x 옵션으로 지정하는데,

node_modules를 지정하지 않았더니 문제가 생겼었다. (node_modules를 zip에 포함시켰더니)

 

 

어자피 .ebextensions에 npm install 키워드가 있기에 node_modules를 zip에 안넣어도 되지만,

어자피 덮어쓰기가 될 줄 알고 딱히 신경쓰지 않았었다.

그랬더니 안됏따아아아ㅏㅏ

정확히는 

 ./lib/cli

를 찾을 수 없다고 에러가 발생했다. 저게 뭔지 모르겠다.

* .ebextensions란 Beanstalk 구성파일로, Beanstalk에 배포될 때 최초에 실행되는 커맨드라고 보면된다.

 

 

우연히 node_modules를 제외시키면서 문제가 해결되긴 했는데 왜 내부에서 충돌이 난것인지는 모르겠다.

혹시 명쾌한 답을 아신다면 댓글 부탁드립니다.

 

 

 

 


삽질한 점

  • ci때와 cd때 둘다 aws cli를 설치해야한다.
  • zip할때 node_modules를 빼줘야한다.

 

 

 

참고:

더보기

+ Recent posts