SSH 프로토콜을 통한 인증
기존까지의 내용은 토큰을 기반으로 push
- 공개키 암호화 방식 활용
- username과 토큰 사용할 필요 없음
- 컴퓨터 자체에 키 저장
SSH 키를 만들어 두면 github뿐만 아니라 ssh를 사용하는 사이트에 함께 사용가능
계정에 Setting에 들어간다음 SSH and GPG keys
우선 SSH키 존재 여부에 대해 확인해야 함
없다면 생성
ssh-keygen -t ed25519 -C "(이메일 주소)"
만든 후 조회해 보았을 때 pub이 붙은것이 공개키, 안 붙은것이 비밀키
GitHub에 키 등록하기
위와 같은 방식으로 컴퓨터의 공개키를 github에 등록하면, 본인 및 특정 누군가가 인증을 진행할때 개인키와 공개키가 맞아 떨어지는지 확인하고 승인을 해줌
기존 HTTTP 기반의 원격저장소를 SSH로 바꾼후, 커밋이 되는 것을 확인
GPG로 커밋 검증
어떠한 커밋에는 verified가 붙어있는 반면, 어떠한 커밋에는 붙어있지 않음
-> 깃헙 자체에서 수정하고 커밋한 커밋들에 verified가 붙어 있음
Verified : 신뢰할 만한 출처에서 커밋되었다는 인증
Settings 에서 GPG 키 생성하기
-> 우선 brew install gnupg
gpg --full-generate-key생성시 real name은 깃헙 계정 이름으로
이후 passphrase 창에서 암호 지정
gpg --list-secret-keys --keyid-format=long
를 통해 만들어 진 것 확인
이후 sec에서 암호 타입 뒤에 있는 문자열 복사(복사1)
gpg --armor --export (위에서 복사한 문자열)위에서 나온 결과값 또한 복사(복사2)하고 이를 깃헙에 붙여넣어 GPG 키 완성
이후 GPG 키를 깃에게 알려주어야 함
git config --global user.signingkey 복사1 키값if [ -r ~/.zshrc ]; then echo 'export GPG_TTY=$(tty)' >> ~/.zshrc; \
else echo 'export GPG_TTY=$(tty)' >> ~/.zprofile; fi이후 커밋할때
git commit -S -am '메세지'
ex) export GPG_TTY=$(tty) -> 비밀 번호 창이 안떠서 추가함
git commit -S -am 'sign commit'
정상적으로 커밋이 verified 됨
태그에 사인을 하고 싶은 경우
git tag -s (태그명) (커밋 해시) -m (메시지)
Github Actions를 통한 자동화
예전엔 Jenkins 많이 사용
CI/CD : 지속적 통합과 배포
-> 동종: GitLab CI/CD, BitBucket Pipelines
CI/CD
젠킨스, Travis CI, Github Actions
CI(Continuous Integration) : 지속적 통합
CD(Continuous Deploymet) : 지속적 배포
최종 배포 과정에서 진행하는 일
Git 에서 여러 개발자들의 코드를 merge 하기 전에 작성한 코드에 문제가 없는지 확인하는 과정이 없으면 실제 서비스를 배포되고 나서 문제가 발생할 수 있음
-> ex) 코드 자체 문제, 합쳤을 때 엇갈리는 코드
-> 큰 프로젝트를 수작업으로 일일히 테스트하기는 힘듬
-> 이를 해결하기 위해 통합 작업을 수시로,지속적으로 하게 해야하는데 이때마다 테스트 과정을 매번 거치기는 번거로움
-> 자동화의 필요성(CI 의 자동화를 위한 많은 도구와 서비스)
배포란 소프트웨어를 코딩한 결과를 최종 사용자에게 넘겨주는, 즉 실행 가능하도록 하는 단계
CI/CD 자동화를 위한 툴
- 젠킨스(설치형)
개발자 컴퓨터나, 서비스가 돌아갈 서버서에 직접 다운받아 사용
웹 사이트에서 작업(매크로 생성)
계정 연동을 해두면 개발자가 원격에 PUSH 시 자동으로 젠킨스 전용 폴더로 다운로드가 됨
테스트 실패시 개발자에게 메세지를 보내 줌
이전 작업에서 문제가 없다면 프로젝트를 배포용 파일로 빌드한 다음 원하는 폴더로 옮겨 돌고 있던 서비스를 중지하고 이 파일로 새 서비스 실행
즉 푸시를 했을 때 서버로 옮겨 테스트를 진행하고 문제 없을시 빌드하여 배포 - Travis
CI(클라우드형 서비스)
설치형으로도 가능, 저장소를 Travis와 연동, Travis의 서버에서 작업이 돌아감
클라우드 서버에서 테스트를 마치고 빌드한 다음 배포할 서버로 전송하는 기능으로 CD도 가능
유료이거나, 제한적 무료 - Github Actions
깃헙 블로그 리포지토리에 푸쉬를 진행한 후 보면
Actions이 추가되어있고 자동으로 코드 내용을 확인한후 배포까지 하여 적용된것을 볼 수 있음
github.io와 다르게 그냥 프로젝트는 actions 등록을 해주어야 함
어떤 종류의 자동화를 하고싶은지 선택하게 됨
-> 프로젝트에 맞는 워크플로우 선택 후 yml 작성
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the "main" branch
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v3
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!
# Runs a set of commands using the runners shell
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
on에는 어떤것에 반응 할지 명시
-> push나 pull_request가 main 브랜치로 가는 것일 때 자동화 진행
job에는 어떤것들을 실행할지
-> 깃헙이 코드를 어디서 작업할지 (ubuntu-latest)
작업 내용 작성 후 커밋 시
workflow 폴더가 생김
로컬에서 작성해서 푸시 해도됨
Github Actions 예시
js 파일은 값이 홀수인 경우 오류
깃헙에 PR을 날렸을 때, 깃헙에서 위 테스트를 진행한 후 오류가 발생하는 경우 자동으로 PR을 취소해준다고 가정
test.yml
name: Node.js CI
on:
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest ## 우분투 가상공간에서 작업 진행
strategy:
matrix:
node-version: [12.x, 14.x, 16.x] ## 해당 버전들에서 호환이 안되는 경우도 테스트 실패
steps:
- uses: actions/checkout@v2
- name: Execute text
run: npm test
- name: if fail
uses: actions/github-script@0.2.0
with:
github-token: ${{github.token}}
script: |
const ref = "${{github.ref}}"
const pull_number = Number(ref.split("/")[2])
await github.pulls.createReview({
...context.repo,
pull_number,
body:"테스트가 실패했습니다.",
event: "REQUEST_CHANGES"
})
await github.pulls.update({
...context.repo,
pull_number,
state: "closed"
})
if: failure() ## 테스트가 실패한 경우 메세지를 담아 해당 PR을 자동으로 close 이후 새 브랜치를 만든 후 값을 101로 바꾼후 push
이후 PR을 만들고 Actions를 확인하면 작업이 돌아감
-> fail이 뜸
실패 후 pr이 closed에 위치
값을 짝수로 하였을 때는 정상으로 PR 반영
OctoTree
브라우저에서는 복잡한 프로젝트 구조를 보기 어려움(finder 같은 것이 생김)
GitHub CLI
깃헙 전용 CLI 툴
