자격증 준비

최근들어 개발자들이 잘 따지않는 자격증에 대한 흥미가 있어 찾던 중, Github에서 제공하는 자격증 시험이 있는것을 봤다.

https://resources.github.com/learn/certifications/

현재는 네가지 자격증을 취득할 수 있는데, 종류는 다음과 같다

Github Foundations : GitHub에서 협업, 기여 및 작업하는 기본 주제와 개념에 대한 이해를 강조
Github Actions : GitHub Actions를 사용하여 워크플로 자동화 및 개발 가속화에 대한 능력을 인증
Github Advanced Security : GitHub Advanced Security 인증을 통해 코드 보안 지식을 강조
Github Administration : GitHub 관리자 시험으로 건강한 GitHub 환경을 최적화하고 관리하는 능력을 인증
Github Copilot : GitHub Copilot 인증 시험은 다양한 프로그래밍 언어에서 AI 기반 코드 완성 도구를 사용하는 기술을 평가 (10월 출시 예정)

자격증 비용으로는 모두 99$ 였으며, Github Foundations의 경우 바우처가 적용되어 49.5$로 응시가 가능했다.

Github 자격증의 경우 국내 블로그 자료를 한번도 본적이 없기 때문에, 딱 이거다 싶어서 바로 자격증 준비를 시작했다. 나는 자격증은 따고 싶으나 별로 내키는 자격증이 없어서 가장 저렴하고 쉬운 foundations를 준비하기로 했다.

아무래도 자료가 없다보니 AWS 자격증을 준비했던 것처럼 편리한 덤프 사이트를 찾기가 어려웠다. 그 중 Github public Repository에서 ghcertified라는 서비스를 볼 수 있었다.

https://github.com/FidelusAleksander/ghcertified

이 서비스는 github 자격증을 준비하는 사람들에게 덤프 문제를 제공해주는 사이트 였는데, 이를 통해 쉽게 공부할 수 있겠다라는 생각을 했다.

하지만 해당 서비스에서 조금 아쉬운점이 있었는데 그것은 바로 구글 번역을 적용 후 다음 문제로 넘어가면, 다시 구글 번역을 적용해야 한다는 점이었다.

부끄럽지만 영어에 익숙하지 않은 나는 이것이 굉장히 불편했다. 그러고보니, 이 레포지토리는 오픈소스로 기여가 가능한 레포지토리 라는점을 깨닫고, 오픈소스 기여를 해야겠다! 바로 생각이 들었다.

오픈소스 기여 할까말까

해당 서비스는 quizdown.js 라는 퀴즈 UI를 빠르게 개발하게 해주는 오픈소스 라이브러리를 사용하고 있었는데, 이 quizdown.js가 바로 다음 퀴즈에 번역이 적용되지 않는 현상이 있었던 것이다. 따라서 이 라이브러리를 살펴보다보니 Svelte라는 언어로 개발되어 있었고, 여기서 포기할까 고민했다. 나는 Svelte를 사용해본적이 전혀 없었기 때문이다. (니꼴라스님 유튜부에서 한번 보긴했다.)

https://github.com/bonartm/quizdown-js

하지만 마음을 다잡고 나는 프로니까 문제가 되는 부분을 천천히 찾아봤고, 나와 동일한 고민을 했던 사람의 StackOverflow 글을 볼 수 있었다.

https://stackoverflow.com/questions/72272843/how-can-i-use-google-translate-directly-on-sveltekit-web-pages

해당 링크의 하단에 이 문제를 또 오픈소스로 만들어서 공유해주신 분이 계셨고, 옳지! 이분의 라이브러리를 quizdown.js에 적용하여 PR을 올리면 되겠다!고 생각했다.

하지만 해당 서비스는 버전 문제가 있었으니,,,

바로 quizdown.js 는 Svelte 3 버전을 사용중이었고, svelte-google-translate 오픈소스는 Svelte 4 버전을 사용중이었다.

어찌저찌 svelte 3에서 4로 마이그레이션 해주는 기능 및 수정이 필요한 부분들을 찾아찾아서 여러가지 시도를 해봤지만, 프레임워크에 대한 지식이 부족하여 아무래도 단기간에 수정하기에는 어려웠다.

따라서, 다른 개발자들의 도움을 얻기로 했다.

오픈소스 고쳐주세요

먼저 svelte-google-translate 오픈소스 개발자님의 레포지토리에 이슈를 생성하여 내가 지금 하고자하는 일에 대해 간략히 설명하고, 하위 호환성을 추가 해줄 수 없냐고 요청드렸다.

그런데 quizdown.js 라이브러리를 4버전으로 올리면 안되냐고 하셔서 제가 못나서 못합니다.. 라고 말씀드렸더니, 이분께서 직접 quizdown.js를 svelte 4 버전으로 마이그레이션 해주셨다!

빨리 PR 봐주세요

하지만 여기서 또 문제가 생겼는데, quizdown.js 라이브러리는 마지막 커밋이 2년전이다. 즉, 더이상 관리되고 있는 라이브러리가 아니었다.

나 지금 이거 빨랑 수정해가지고 자격증 공부하고싶은데, PR 리뷰가 너무 늦어지는 문제가 있었다.

그래서 포크떠서 내가 적용했다.

이러면 안될것 같지만, 내가 quizdown.js 라이브러리를 수정하고, 해당 라이브러리를 적용한 버전의 ghcertified 개인 레포지토리를 새로 팠다. 나처럼 Github 자격증을 따는데 번역 문제로 불편함을 느끼는 사람이 있다면 활용해줬으면 좋겠다. 기능들은 이미 넣어놨으니, ghcertified의 로컬에서 실행하기 위한 문서를 읽고, 로컬에서 해당 서비스를 실행하여 사용한다면 번역 하는데에 번거로움 없이 문제를 풀 수 있다.

https://github.com/gogoadl/ghcertified

느낀점

해외 개발자들과 소통하는 것은 굉장히 재미있기도 하고 많은 경험이 되는 것 같다. 이번 경험을 통해서는 말하는 감자와 같은 나의 요청에 흔쾌히 타인의 오픈소스를 수정해주신 개발자님께 감사를 드리고 싶다. 자 이제 자격증 공부하로 가뿌자

git-submodule

하나의 저장소에서 다른 저장소를 포함하고 관리할 수 있게 해주는 기능

주로 의존성 관리 및 외부 프로젝트 통합에 사용

어떻게 적용하는가

git submodule add {대상 레포지토리}

위 명령어 수행 시 github desktop에서 두가지 파일이 stage 되는것을 알 수 있다.

근데 git add랑 git stage랑 무엇이 다른걸까?

아래의 링크에서 볼 수 있듯이 똑같다고 한다. 이제 다음 스텝으로 가자

https://superuser.com/questions/1395627/differences-between-git-add-and-git-stage

gitmodules 파일에 아래의 내용이 추가 되었다.

[submodule "github-submodule-test"]
    path = github-submodule-test
    url = https://github.com/gogoadl/github-submodule-test.git

branch를 직접 지정해줄수도 있다고 한다.

또한 submodule을 추가 했던 레포지토리 자체의 변경사항도 있다고 나온다.

위 내용을 푸쉬하면 submodule이 등록된것을 확인 할 수 있다.

submodule 업데이트 반영

submodule을 포함하여 개발 중 submodule의 업데이트가 발생할 수 있다. 이를 반영하는 방법은 아래와 같다.

# .gitmodules 파일에 정의되어 있는 브랜치의 최신 버전으로 업데이트 (혹은 default 브랜치)
git submodule update --remote

역시나 다양한 케이스의 업데이트 방식을 지원하는 것 같다. 궁금하면 좀 더 찾아보자.

submodule 실제 활용 케이스 살펴보기

예전에 한글화에 기여했었던 서비스인 fxsound의 경우 서비스의 문자열 데이터를 저장하고 있는 Strings 레포지토리를 submodule로 관리하는 것을 알 수 있다.

현재 기여를 준비하고 있는 gihub가 주관하는 자격증의 시험 문제 덤프 서비스인 ghcertified에서도 .gitmodules로 서브모듈을 관리하고 있다. (이미지에 노란색으로 표시했다.)

이 프로젝트에서는 레포지토리 자체에서 submodule을 가지고 있지 않고, 필요할 때 submodule update를 통해 가져오도록 문서에서도 안내하고 있다.

마무리

submodule이 무엇인지, submodule을 어떻게 활용할 수 있는지 간단히 살펴보았다.

지금 당장 나에게 필요한 기능은 아니지만, 추후 필요할 때 사용할 수 있게끔 숙지해두자.

Github Security

왜 사용하나

오픈소스와 같은 많은 사용자들이 이용하는 소스코드에 취약점이 발견 될 경우, Security 탭에서 취약점을 보고 할 수 있다.

취약점을 보고 할 경우 가시성은 해당 레포지토리의 관리자 및 협력자에게만 표시되며, 이를 통해 해당 취약점을 내부 관계자들이 파악하고 조치할 수 있다.

Github Security Policy

저장소에 보안 정책을 추가하여 프로젝트의 보안 취약점을 보고하는 방법에 대한 지침을 제공 할 수 있다.

Github 에서는 각 레포지토리마다 각자의 다양한 정책을 가지고 있다. 예를 들면 Pull Request Template, Issue Template 또는 Contributor가 되기 위해 미리 숙지 해야할 것들과 같이, 보안 이슈를 보고하기 위해서도 사용자들이 보안 취약점을 보고하기 위한 가이드를 제공할 수 있다.

어떻게?

저장소의 루트, docs, .github 폴더에 SECURITY.md 파일을 추가할 수 있다. 이 파일을 앞에 언급한 저장소의 폴더에 생성 할 경우 사람들이 검토할 수 있는 설명이 있는 행이 자동으로 생성된다.

이를 통해 다른 사용자가 취약점 보고를 위한 가이드라인과 정보를 얻을 수 있다.

Github Report Vulnerabilities

만약 레포지토리의 소스코드에서 보안 취약점을 발견 한 경우 Private vulnerability reporting 을 활성화 하여 사용자들로부터 보안 취약점 보고를 받을 수 있다.

이를 활성화 한 경우 보안 취약점을 보고 할 수 있는데, 아래와 같은 폼으로 해당 보안 취약점에 대해 자세히 설명할 수 있다.

아무래도 보안 취약점이므로, 어떤 문제가 발생하는지, 이슈 재연 시나리오 및 해당 취약점을 검증하는 프로세스가 기본 폼으로 작성되어 있다.

마무리

짧지만, 최근들어 Github Foundations를 공부하면서 Github에서 제공하는 다양한 기능들을 간단히 소개해보고자 한다. Github Foundations는 국내에서 검색했을 때 자료가 없었고, 여기서 배운 내용들이 한국 개발자들이 Github를 더 효율적으로 사용하고, 필요했었지만 기능의 존재 유무조차 알지 못해 넘어갔던 부분들을 어느정도 해소시킬 수 있지 않을까 생각한다.

Github 시험 오답노트

Github가 오픈소스 프로젝트에 대해 제공하는 것

• 소프트웨어 개발 워크플로우 전반에 걸쳐 학습하고 활용할 수 있는 모범 사례
• 소프트웨어 개발 기능 및 서비스
• 보고된 보안 취약점을 식별하고 수정하기 위한 코드 스캐닝

-> 법적 준수는 강제하지 않는다.

Github Organization내의 청구 관리자가 수행 가능한 것

• 계정 업그레이드, 다운로드
• 결제 방법 추가, 업데이트 또는 제거
• 결제 내역 보기
• 영수증 다운로드
• 청구 관리자 보기, 초대 및 제거
• 스폰서십 시작, 수정 또는 취소
• 모든 청구 관리자는 조직의 청구일에 이메일로 청구 영수증을 받게 된다.

수행할 수 없는 것

• 조직에서 저장소를 만들거나 액세스
• 조직의 비공개 회원 보기
• Github Marketplace 앱에 대한 구독, 구매, 편집 또는 취소
• Github Copilot Business 구독 구매, 편집 또는 취소

Github Repository에서 이슈를 생성 할 수 있는 사람은?

• 저장소에 대한 읽기 액세스 권한이 있는 모든 Github 사용자

Gist를 만들기 위해서는 저장소 홈페이지 대신 Gist 홈페이지로 이동하여 생성할 수 있다.

Github Projects Insight를 통해 팀원에게 할당된 항목 수를 시각화 하는 차트 만들기

현재 차트 - 각 개인에게 할당된 항목 수, 각 다가올 스프린트에 할당된 이슈 수

기록 차트 - 사용자에게 할당된 기존 항목이 아닌 프로젝트 항목의 상태 변경 사항 추적
사용자 차트 - 유효한 차트 유형이 아님.
프로젝트 차트 - 유효한 차트 유형이 아님.

Github Projects에서 사용 가능한 레이아웃 종류

• 보드 레이아웃 - 칸반 보드 형식
• 로드맵 레이아웃 - WBS 형식?
• 테이블 레이아웃 - 노션 데이터베이스 형식

리스트 레이아웃은 존재하지 않음.

Github Mobile에서 사용할 수 있는 기능

• 이슈, 풀 리퀘스트를 읽고, 검토 및 협업
• 알림 관리, 분류 및 지우기
• 풀 리퀘스트에서 웹 기반 코드 편집

Github Mobile에서 사용할 수 없는 기능

자동화된 테스트 및 지속적인 통합

Github Advanced Security (GHAS) 라이센스에 포함되는 기능

1. 종속성 검토 - 풀 리퀘스트 병합 전 종속성 변경 사항의 전체 영향을 보여주고 취약한 버전의 세부정보 확인
2. 비밀 스캐닝 - 키와 토큰과 같은 비밀 감지, 푸시 보호가 활성화된 경우 저장소 푸시될 때 비밀도 감지
3. 코드 스캐닝 - 코드에서 잠재적인 보안 취약점과 코딩 오류 검색

Github Projects를 사용하면 조직 프로젝트, 사용자 프로젝트 두 가지 유형의 프로젝트 생성 가능

Codespaces를 효율적으로 리소스 활용을 보장하며 비용을 줄이는 방법

-> Codespace 자동 삭제를 위한 기본 보존 기간을 줄인다.
비활성 코드스페이스는 자동 삭제된다. 또한, 중지된 코드스페이스를 보관할 기간을 최대 30일 까지 선택할 수 있다. 그러나 Codespaces는 스토리지 요금이 부과되므로 기본 기간을 변경하여 보관 기간을 줄이는 것이 좋다.

Github 무료 플랜에서는 이슈 및 풀 리퀘스트에 공개 저장소의 경우 최대 10명, 비공개 저장소의 경우 1명까지 할당 가능하다.

Github Actions 구성 요소 중 동일한 러너에서 실행되는 단계로 구성되는 것은
-> Job

Event - 워크플로 실행을 트리거하는 특정 활동
Action - 실행되는 스크립트
Workflow - 하나 이상의 Action을 실행하는 전체 프로세스

Github Issue Form

Github를 사용하면서 주로 이슈 템플릿을 활용하여 이슈를 관리 했었는데, Github Foundations를 공부하면서 다른 형식으로 이슈 관리를 제공하는 Issue Form에 대해 알게되어 소개하고자 글을 포스팅 합니다.

이미 Github Issue Template를 사용해 본 경험이 있고, Github에 친숙한 분들을 대상으로 빠르게 글을 작성해봅니다.

Issue Form 생성하기

Issue Form은 기존 이슈 템플릿과 동일하게 레포지토리 내의 .github/ISSUE_TEMPLATE/ 경로에서 이슈 폼 파일을 정의할 수 있습니다.

사용하고자 하는 폼의 유형에 따라 .yml 파일을 정의하면 되는데, Github 문서 에서 제공하는 기본 이슈 폼을 그대로 작성해보겠습니다.

아래의 내용으로 .github/ISSUE_TEMPLATE/bug.yml 파일을 생성 합니다.

자세한 yml 파일 구성 양식은 Github Issue Form 공식 문서에서 확인할 수 있습니다.

https://docs.github.com/ko/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

name: Bug Report
description: File a bug report.
title: "[Bug]: "
labels: ["bug", "triage"]
projects: ["octo-org/1", "octo-org/44"]
assignees:
  - octocat
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!
  - type: input
    id: contact
    attributes:
      label: Contact Details
      description: How can we get in touch with you if we need more info?
      placeholder: ex. email@example.com
    validations:
      required: false
  - type: textarea
    id: what-happened
    attributes:
      label: What happened?
      description: Also tell us, what did you expect to happen?
      placeholder: Tell us what you see!
      value: "A bug happened!"
    validations:
      required: true
  - type: dropdown
    id: version
    attributes:
      label: Version
      description: What version of our software are you running?
      options:
        - 1.0.2 (Default)
        - 1.0.3 (Edge)
      default: 0
    validations:
      required: true
  - type: dropdown
    id: browsers
    attributes:
      label: What browsers are you seeing the problem on?
      multiple: true
      options:
        - Firefox
        - Chrome
        - Safari
        - Microsoft Edge
  - type: textarea
    id: logs
    attributes:
      label: Relevant log output
      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
      render: shell
  - type: checkboxes
    id: terms
    attributes:
      label: Code of Conduct
      description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com). 
      options:
        - label: I agree to follow this project's Code of Conduct
          required: true

성공적으로 레포지토리 내에 파일을 생성 한 경우, Github에서 새로운 이슈를 생성하면 다음과 같이 이슈 폼을 선택할 수 있습니다.

이슈 생성 화면을 보면 기존 이슈 템플릿보다 편리하고 구조화된 이슈를 생성하는 폼을 제공합니다. 

생성된 이슈는 이슈 템플릿으로 생성한 형식과 동일하게 표시됩니다.

이슈폼을 직접 생성해보면서 느낀점은 이슈의 형식에 좀더 제한을 두어, 더욱더 강력하고 편리하게 이슈를 관리할 수 있겠다고 느꼈습니다. 다음에 Github 에서 프로젝트를 관리할 일이 생긴다면, 이슈 폼을 적극 도입하지 않을까 합니다.

또한, 현재 이슈 폼은 베타 버전으로 언제든지 변경될 가능성이 있다고 합니다.

Git 용어

• 작업 트리 : 작업 중인 프로젝트가 들어 있는 중첨된 디렉토리와 파일의 집합
• 저장소 : 작업 트리의 최상위에 위치한 디렉토리, 모든 기록과 메타데이터를 보관
• 해시 : 해시 함수에 의해 생성된 숫자로, 파일이나 다른 객체의 내용을 고정된 숫자로 나타냄. Git은 160비트 길이의 해시를 사용
• 객체 : 블롭객체 - 일반 파일, 트리객체 - 디렉토리, 커밋객체 - 특정 버전,

SCM 소프트웨어 구성 관리 시스템 = VCS

git merge --abort
현재 진행중인 merge를 모두 삭제하고 merge를 시도하기 전으로 되돌림.

개인 저장소
본인, 본인이 명시적으로 접근 권한을 공유한 사람, 조직 저장소의 경우 특정 조직 구성원만 접근 가능

Github 계정 유형

Personal

• Github Free, Github Pro
• Guthub Free 사용자의 경우 개인 계정이 소유한 비공개 저장소는 제한된 기능 사용가능

Organization

• 계층적 접근 방식
• 조직 소유자 및 보안 관리자만이 조직의 설정을 관리 및 데이터에 대한 액세스 제어

Enterprise

• 관리자가 여러 조직의 정책과 청구를 중앙에서 관리하고 조직간의 내부 소싱을 활성화
• 조직 수준에서 정책에 사용할 수 있는 옵션 제어
  • SSO를 통한 인증
  • 보안, 규정 준수 및 배포 제어 강화
  • Github Actions를 사용한 비공개 또는 내부 저장소에 대한 배포 보호 규칙 Github Connect
• Github Enterprise Server - 조직이 인프라를 완벽하게 제어
• Github Enterprise Cloud

Github 청구

• 구독 : Github Pro, Github Team과 같은 사용자 계정 플랜과 Github Copilot, Github Marketplace와 같은 월별 비용이 발생하는 유료 제품 포함
• 사용 기반 청구 : 유료 제품의 비용이 제품을 얼마나 많이 사용하느냐에 따라 달라질 때 적용

Github Copilot

• ChatGPT와 유사한 경험 제공

  개발자 시나리오에 초점을 맞춘 편집기에 채팅 인터페이스를 제공하여 VS Code, Visual Studio와 기본적으로 통합됨.
  개발자가 입력한 코드, 표시된 오류 메세지를 인식하며 IDE에 내장되어 있다.
  개발자는 코드 블록이 수행하려는 작업에 대한 심층 분석 및 설명을 얻고, 단위 테스트 생성, 버그에 대한 제안된 수정사항을 얻을 수 있다.

• Pull Request를 위한 Copilot

• 문서에 대한 AI 생성답변

• 명령줄 인터페이스를 위한 copliot

• Github Copilot Business

• 회사에서 누가 Github Copilot을 사용할 수 있는지 제어할 수 있다.

• Github Copilot Enterprise

  조직을 위한 추가 개인화 계층과 개발자가 플랫폼 전체에서 코드베이스와 작업 버튼에 대해 대화할 수 있도록 하는 채팅 인터페이스로 Github와 통합

Github Codespace

Codespace를 만드는 방법

• Github 템플릿이나 Github.com의 템플릿 저장소를 이용해 새로운 프로젝트 시작
• 저장소의 브랜치에서 새로운 기능 작업
• 공개된 풀 리퀘스트를 통해 진행 중인 작업 살펴보기
• 저장소 기록의 커밋에서 특정 시점의 버그 조사

일시적으로 Codespace를 사용하여 코드 테스트, 동일한 Codespace로 돌아와 장기적으로 실행되는 기능 작업을 진행할수도 있다.

Github Project

Inner Source

제한된 대상을 가진 프로젝트에 오픈소스 패턴을 적용하는 관행.

ex) 어떤 회사는 일반적인 오픈소스 프로젝트의 구조를 반영하는 InnerSource 프로그램을 만들수 있지만, 그 회사의 직원만 접근할 수 있다.

회사의 방화벽 뒤에 있는 오픈소스 프로그램

InnerSource의 이점

1. 투명성 장려

   다른 회사 프로젝트의 소스코드에 대한 액세스는 생산성을 높이는데 도움이 될 수 있다. 다른 팀이 직면한 것과 유사한 문제를 어떻게 해결했는지와, 재사용할 수 있는 코드와 자산을 찾을 수 있다.

2. 마찰을 줄인다

   소비자 팀이 다른 팀이 소유한 프로젝트의 버그 수정이나 새로운 기능에 의존하는 경우, 그들은 필요한 변경사항을 제안할 수 있는 채널을 가질 수 있다.

3. 관행을 표준화

   InnerSource 프로그램을 구축하는 것은 동일한 관행을 따르지 않더라도 모든 개발 팀에서 사용할 수 있는 표준 규칙을 채택할 수 있는 좋은 기회이다.

저장소 가시성 및 권한 설정

• 공개 저장소 : 이 가시성은 진정으로 오픈소스이며, 조직 내부, 외부 사람들에게 액세스를 제공하는 프로젝트에 사용
• 내부 저장소 : 소유한 조직의 구성원에게만 표시. InnerSource 프로젝트에 이 가시성을 사용
• 비공개 저장소 : 소유자 및 그들이 추가한 팀 또는 개인에게 표시. 특정 사용자와 그룹만 액세스 할 수 있는 프로젝트에 이 가시성을 사용

권한 수준

• 읽기 : 프로젝트를 보거나 논의하고 싶은 비코드 기여자에게 권장
• 트리아지 : 쓰기권한 없이 이슈와 풀리퀘스트를 적극적으로 관리하는 기여자
• 쓰기 : 프로젝틍 ㅔ적극적으로 참여하는 기여자
• 수준 유지 : 민감하거나 파괴적인 작업에 접근하지 않고 저장소를 관리하는 프로젝트 관리자
• 관리자 : 프로젝트에 대한 전체 액세스 권한

안전한 Github 저장소를 유지하는 방법

보안 애플리케이션을 빌드하고 배포하는 데에 고려해야 할 세가지 사항

• 일반적인 지식 문제

  많은 개발자와 직원들이 보안을 이해한다고 생각하지만, 실제로 그렇지 않다. 지속적인 교육 및 훈련 프로그램이 필수적이다.

• 코드는 올바르고 안전하게 생성되어야 함

  기능이 보안을 염두에두고 설계되었는지도 확인해야 한다.

• 애플리케이션은 규칙과 규정을 준수해야 함

  코드를 빌드하는 동안 준수 여부를 테스트하고 배포 후에도 주기적으로 다시 테스트 해야한다.

보안 탭 기능

Github는 저장소와 조직 전반에서 데이터를 안전하게 유지하는데 도움이 되는 보안 기능을 제공한다.

• SECURITY.md 저장소에 파일을 추가하여 프로젝트의 보안 취약점을 보고하는 방법을 지정할 수 있는 보안 정책
• Github에서 저장소가 취약한 종속성이나 멀웨어를 사용하고 있음을 감지하면 알려주는 Dependabot 알림
• 코드의 취약점과 오류를 찾고, 분류하고, 수정하는데 도움이 되는 코드 스캐닝

Github Authentication

Github에서 인증하는 데에는 여러가지 옵션이 있다.

• 사용자 이름과 비밀번호
• 개인 액세스 토큰 (PAT)
• SSH 키

Github의 추가 보안 옵션

• 2FA
• SAML SSO
• LDAP
  Lightweight Directory Access Protocl(LDAP)는 디렉토리 정보 서비스에 액세스하고 유지하기 위한 애플리케이션 프로토콜. 타사 소프트웨어를 대기업 사용자 디렉토리와 통합하는데 사용되는 가장 일반적인 프로토콜

팀 권한 수준

조직 권한 수준

엔터프라이즈 권한 수준

CODEOWNERS 파일 추가

팀원이나 전체 팀을 저장소의 코드를 담당하는 코드 소유자로 지정 가능. 누군가가 코드 소유자에게 속한 코드를 수정하는 풀 리퀘스트를 열면 코드 소유자는 자동으로 검토자로 요청 됨

Github Action으로 Android 앱 github Release에 배포하기

개요

사이드 프로젝트 compose-cocktail-recipes 앱을 제작하던 중, github actions를 통해 CI 뿐만 아니라 CD까지 자동화로 진행 가능 하도록 구성하기로 했습니다. 따라서 이 글에서는 github actions에서 서명된 APK를 빌드하고 릴리즈하는 과정을 소개합니다.

CI/CD 구성하기

제가 CI/CD를 구성하는데에 필요했던 기능은 다음과 같습니다.

• main branch의 push 이벤트, pull-request 이벤트 발생 시 debug 빌드
• main branch에서 태그 생성 시 서명된 APK를 생성
• 앱의 versionCode, versionName도 자동화하여 생성
• 자동으로 github releases에 서명된 APK를 업로드

main branch의 push 이벤트, pull-request 이벤트 발생 시 debug 빌드

해당 작업은 github actions에서 제공하는 기본 Android CI 템플릿을 적용하여 쉽게 작업할 수 있었다.

아래처럼 github actions가 구성되지 않은 상태에서 Actions 탭을 선택하면 workflow를 검색할 수 있는데, 여기 android라고 검색하면 제일 먼저나오는 ”Android CI”를 configure 하면된다.

선택했다면 아래와 같이 기본적인 빌드를 수행하는 workflow 템플릿이 나오는데, 나는 여기서 태그 생성 이벤트 감지와 릴리즈 빌드를 수행하는 job을 추가로 구성했다.

github releases에 서명된 APK를 업로드

많은 사람들이 이미 시도했던 내용이었으며, 생성한 keystore 정보를 github secret으로 생성하여 저장하고, keystore 파일 자체는 base64 인코딩한 정보를 저장한 후 github actions 수행 중 다시 파일로 변환하는 방법이 있었다.

자세한 내용은 수빈박님의 블로그를 참고했다.

앱의 versionCode, versionName도 자동화하여 생성

chkfung 개발자님의 [android-version-actions@v1.2.1](https://github.com/chkfung/android-version-actions) 라는 커스텀 액션을 발견하여 그대로 적용했고, 남은 자동으로 github releases에 서명된 APK를 업로드 기능을 커스텀 액션으로 개발하여 MarketPlace에 배포하기로 결정했다.

완성된 workflow 파일은 아래와 같다.

name: Android CI

on:
  push:
    branches:
      - main
    tags:
      - 'v*.*.*'
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'
          cache: gradle

      - name: Grant execute permission for gradlew // gradlew 사용권한 주기
        run: chmod +x gradlew

      - name: Set output // tag 이름을 버전정보 변수에 저장
        id: vars
        run: echo "tag=${GITHUB_REF#refs/*/}" >> $GITHUB_OUTPUT
      - name: Check output
        env:
          RELEASE_VERSION: ${{ steps.vars.outputs.tag }}
        run: |
          echo $RELEASE_VERSION
          echo ${{ steps.vars.outputs.tag }}

      - name: Bump version // 앱의 versionCode, versionName 설정
        uses: chkfung/android-version-actions@v1.2.1
        with:
          gradlePath: app/build.gradle # or app/build.gradle.kts
          versionCode: ${{github.run_number}}
          versionName: ${{env.RELEASE_VERSION}}

      - name: Build Debug APK // debug 빌드
        run: ./gradlew assembleDebug

      - name: Upload artifact Debug APK // github action artifact에 apk 업로드
        uses: actions/upload-artifact@v3
        with:
          name: apk
          path: app/build/outputs/apk/debug/*.apk

  release:
    permissions: // github releases 쓰기 권한 얻기
      contents: write
    needs: build
    if: startsWith(github.ref, 'refs/tags/v') // 태그 생성 되었다면
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3 # Necessary to access local action
      - name: github-action-release-apk // release 빌드 및 github Releases 배포
        uses: gogoadl/github-action-release-apk@v1.0.0-alpha09
        with:
          asset-name: 'Cocktails.apk'
          github-token: ${{ secrets.GITHUB_TOKEN }}
          base64-keystore: ${{ secrets.APP_KEYSTORE_BASE64 }}
          key-file: ${{ secrets.APP_KEY_FILE }}
          keystore-password: ${{ secrets.APP_KEYSTORE_PASSWORD }}
          keystore-alias: ${{ secrets.APP_KEYSTORE_ALIAS }}
          key-password: ${{ secrets.APP_KEY_PASSWORD }}

위 작업을 통해 위에서 내가 언급했던 작업들을 자동화 할 수 있었다.

해당 커스텀액션의 내부구현이 궁금하다면 github-action-release-apk 레포지토리에서 확인할 수 있다!

개요

저는 개발용 PC로 집에서 사용하는 Windows 데스크탑과, 집 밖에서 사용하는 Mac 두 PC로 주로 개발을 진행하는데요.

이렇게 여러 환경에서 개발을 진행 할 경우 작업을 완료하지 않은채로 github에 작업사항을 commit 하게되는 경우가 있는데요. 이러한 노트북 + 데스크탑 또는 Windows 노트북 + MacBook 환경과 같이 여러 환경에서 프로젝트 작업 시 PC의 작업사항을 stash로 옮기는 방법을 소개합니다.

먼저 작업사항을 stash 한 이후 아래의 작업을 이어가시면 됩니다.

Stash를 Patch로 만들기

1. PC의 가장 최근 stash 작업사항을 changes.patch 파일로 저장

$ git stash show "stash@{0}" -p > changes.patch

1. stash를 적용하고자 하는 PC로 해당 파일을 전송
2. 해당 PC에서 patch파일을 적용

$ git apply changes.patch

위의 기능을 통해 다른 PC에서 작업하던 사항을 쉽게 적용하여 작업을 이어갈 수 있습니다.

Reference

https://stackoverflow.com/questions/3973034/export-a-stash-to-another-computer

소스트리에서 remote branch로 push 실패함.

오류로그에서 아래 링크가 있었음.

https://github.blog/2021-09-01-improving-git-protocol-security-github/

맥 개발환경에서 갑자기 소스트리에서 remote branch로 push되지 않는 현상 발생!

처음에는 이런 에러가 떴었다.

webview remote: Permission to username/repository.git denied to username. fatal: unable to access 'https://github.com/username/repository.git/': The requested URL returned error: 403 Completed with errors, see above

갑자기 권한 문제로 머 푸쉬가 안된다는 소리인거 같은디..

이후 소스트리 종료 후 재시작하고, 원격 저장소에서 같은 레포를 클론해봤는데 

/home/username/.ssh/config: line 4: Bad configuration option: IdentifyFile/home/username/.ssh/config: terminating, 1 bad configuration optionsfatal: The remote end hung up unexpectedly

요런 에러 발생!

ssh config 파일 쪽에서 문제가 있는 것 같아서 경로로 들어가서 파일을 봤따

cd /Users/username/.ssh

이 후 vi config 실행

이후 오류 로그에서 본 4번째 줄의 딱봐도 수상해보이는 IdentifyFile ~/.ssh/id_ed25519 를 주석처리 한 후 다시 push에 성공했다!!

Host *

  AddKeysToAgent yes

  UseKeychain yes

# IdentifyFile ~/.ssh/id_ed25519

# --- Sourcetree Generated ---

Host gogoadl-GitHub

        HostName github.com

        User gogoadl

        PreferredAuthentications publickey

        IdentityFile /Users/hyeonwoo/.ssh/gogoadl-GitHub

        UseKeychain yes

        AddKeysToAgent yes

# ----------------------------

하 이거때문에 한 한시간 버렸다 또...

같은 오류를 겪으시는 분들이 얼렁 해결하시길 ^0^