Tag를 이용한 QA 환경 배포와 워크플로우 구성 질문

안녕하세요 메가님~질문에 대한 답변드리겠습니다. 강의에서는 GitHub Actions 기반의 여러 CICD 시나리오를 보여드리기 위해 되도록 간단한 시나리오로 구성했습니다. 1번 질문에 대한 답변을 드리면 QA 배포 시, 수정 사항이 발생할 때마다 버전을 올려서 사용하는 방식으로도 가능합니다.A 기능을 개발 환경에 배포한 후, v1.0.0 태깅하여 QA 환경에 배포하고A 기능을 업데이트하여, 다시 개발 환경에 배포한 후, v1.0.1 태깅하여 QA 환경에 배포할 수 있습니다.현재 강의 구성으로는 수정이 발생할 때마다 이렇게 버전을 업데이트해야 동작하는 구조로 되어있습니다.그런데, 이 방식이 과연 실무에서도 적합할지에 대한 의문이 생기실 수 있습니다. 그래서, 이 질문을 바탕으로 실무에서 활용할 수 있는 좀 더 유용한 구조를 설명드리고자 합니다. 아래는 강의 내용을 조금 벗어나지만, 실무에서 자주 사용되는 방식 중 하나입니다. 시나리오의 방식처럼 구성해서 실무에서 사용하는 데에는 어려움이 있을 수 있습니다.특히 수정 사항이 잦거나 여러 기능이 동시에 QA 환경에서 테스트되어야 할 경우, 관리가 복잡해질 수 있습니다.실무에서는 각 회사와 팀의 배포 전략, 워크플로우 복잡도에 따라 CICD 설계 방식이 달라지기 때문에 정확한 답은 없지만, 하나의 예시를 통해 이해를 도울 수 있도록 설명드리겠습니다. 2024년 11월 30일에 특정 서비스에 여러 기능(A, B, C)을 추가하여 v5.0.0 버전을 운영 환경으로 배포하기로 일정이 정해졌다고 가정하겠습니다.최종적으로 원하는 구조는:release/v5.0.0 브랜치에서 QA 환경 배포가 반복적으로 이루어지고, 최종적으로master 브랜치로 병합하여 운영 환경에 반영되는 것입니다.이를 위해 릴리즈 브랜치와 RC 태그(Release Candidate 태그)를 활용합니다.릴리즈 브랜치: QA 환경에서 테스트를 통과한 안정적인 상태를 유지하며, 운영 환경 배포를 준비하는 역할을 합니다.RC 태그: QA 환경 배포 시점마다 관리되어, 각 배포의 상태를 명확히 기록하고 문제를 추적하기 쉽게 합니다.1. A 기능 개발 및 QA 환경 배포먼저 A 기능이 개발되어 개발 환경에 배포가 완료된 상태입니다.이를 QA 환경에 배포하기 위해 v5.0.0-rc.1 태그를 사용하여 GitHub Actions를 트리거하고, A 기능을 QA 환경에 배포합니다.QA 환경 배포가 성공하면 release/v5.0.0 브랜치가 생성됩니다.이 시점에서 release/v5.0.0 브랜치는 A 기능에 대한 코드만 포함하고 있습니다. 2. QA에서 수정 사항 반영 및 재배포QA 환경에서 A 기능 테스트 중 문제가 발견되었다면, A 기능을 수정하는 커밋을 추가하여수정된 코드를 QA 환경에 다시 배포하기 위해 v5.0.0-rc.2 태그를 사용합니다.이 과정에서 release/v5.0.0 브랜치에는 A 기능뿐만 아니라 수정된 코드가 추가됩니다.QA 테스트는 A 기능이 QA 환경에서 안정적으로 동작할 때까지 이 과정을 반복하며, 최종적으로 release/v5.0.0 브랜치는 A 기능과 모든 수정 사항을 포함하게 됩니다.3. B & C 기능 개발 및 QA 환경 배포A 기능에 대한 QA 테스트가 완료된 후, B와 C 기능이 각각 개발되어 개발 환경에 배포됩니다.이후 B와 C 기능을 QA 환경으로 배포하기 위해 v5.0.0-rc.3 태그를 사용하여 QA 환경에 배포합니다.이때 B와 C 기능에 대한 커밋은 순차적으로 release/v5.0.0 브랜치에 추가됩니다.QA 환경에서는 A, B, C 기능이 모두 포함된 상태에서 통합 테스트가 진행됩니다.QA 테스트 중 문제가 발견될 경우, 이를 다시 수정하는 커밋을 추가한 후 새로운 rc 태깅(ex. rc-4)을 통해 QA 환경에 배포합니다.그리고 새로운 rc 태깅의 커밋은 release/v5.0.0 브랜치에 반영되도록 구성합니다. 4. QA 테스트 완료 후 운영 환경 배포모든 QA 테스트를 통과한 후, release/v5.0.0 브랜치는 최종적으로 안정적인 상태가 됩니다.이제 이 브랜치를 운영 환경 배포를 위해 master 브랜치로 병합합니다.운영 환경에서는 최종 릴리스 태그(예: v5.0.0)를 사용하여 배포가 진행됩니다.이런 구조를 활용한다면, QA 환경에서 버전을 매번 올릴 필요가 없고 필요한 기능이 모두 포함된버전을 운영 환경에 반영할 수 있습니다.처음 강의를 계획할 때, 이 내용으로 강의를 구성하려 했습니다.그런데, 생각보다 내용이 복잡합니다. 특히 말로 설명하기엔 더 어려운 부분이 있어서 강의에서는 간단한 시나리오로 구성했습니다.추가적으로 질문 주신다면, 좀 더 쉽게 이해하실 수 있도록 설명드리겠습니다. 이어서, 2번에 대한 답변을 드리겠습니다.질문 주신 워크플로우 파일의 관리 방식은 선택사항입니다.잡이 추가될수록 워크플로우 파일의 복잡성이 증가하기 때문에, 필요에 따라 파일을 분리하는 것도 좋은 방법입니다.예를 들면, PR이 open or synchronize 되는 경우에는 CI.yaml을 구성해서 테스트만 실행하고PR이 merge 되는 경우에는 CD.yaml을 구성해서 배포만 진행할 수 있습니다.어떤 방식이 더 적합한지는 팀의 CICD 설계와 작업 흐름에 따라 다릅니다.일반적으로는 하나의 파일로 구성하는 경우가 많지만, 복잡성이 증가할 경우 파일을 분리하는 것이 더 효율적일 수 있습니다.

애플리케이션 실행시 환경 변수에 대해서

안녕하세요 ~질문해주신 내용이 단순히 GitHub Actions의 기능을 넘어 어떻게 시크릿을 처리할지에 대한 것이네요이 주제에 대해 명확하게 “이렇게 해야 한다”라고 말씀드리기는 어렵지만, 참고할 수 있는 여러 가지 방법을 설명드리겠습니다.애플리케이션을 운영하다 보면 DB 엔드포인트, 토큰, API 키와 같은 민감 정보를 다뤄야 하는 경우가 많습니다. 이런 정보를 안전하게 관리하기 위해 보통 다음과 같은 방법을 활용합니다.A. GitHub Actions Secrets 사용GitHub Actions에서 제공하는 시크릿 기능은 특정 job이나 step에서 민감 정보를 안전하게 전달하는 데 유용합니다. 예를 들어, Docker 로그인이나 AWS 접근이 필요할 때 GitHub Actions Secrets에 저장된 정보를 활용할 수 있습니다.하지만, 애플리케이션 구동과 관련된 민감 정보는 GitHub Actions Level에서 직접 처리하지 않고, 애플리케이션 초기화 단계에서 필요한 정보를 불러오는 방식으로 운영하는 경우가 많습니다. B. Docker Build 시 --build-arg 사용Docker 빌드 과정에서 --build-arg를 통해 시크릿 값을 전달하는 방법도 가능하긴 하지만, 이렇게 하면 Docker 이미지 레이어에 민감 정보가 그대로 남을 수 있어 보안상 문제가 생길 수 있습니다. C. 외부 시크릿 관리 도구 사용 더 안전한 방법으로는 AWS Secrets Manager나 HashiCorp Vault 같은 외부 시크릿 관리 도구를 사용하는 방법이 있습니다. 예를 들어, AWS Secrets Manager는 IAM 권한을 통해 애플리케이션 초기화 시 필요한 정보를 안전하게 불러올 수 있도록 지원합니다. HashiCorp Vault는 더욱 강력한 시크릿 관리 기능과 인증 방식을 제공하며, 시크릿을 필요할 때만 가져오는 방식으로 안전하게 관리할 수 있습니다.D. 애플리케이션 초기화 단계에서 시크릿 로드컨테이너 환경에서 애플리케이션을 구동한다면, Init Container를 사용하여 민감 정보를 외부 저장소에서 불러와 특정 경로에 파일로 저장한 후, 애플리케이션 컨테이너가 실행될 때 해당 정보를 참조할 수 있습니다. 쿠버네티스를 사용 중인 환경에서는 이런 방식을 활용하기도 합니다. 이렇게 다양한 방법 중에서 애플리케이션의 보안 요구사항에 맞는 방식으로 선택하시면 됩니다. 시크릿이 빌드 단계에서 이미지에 포함되지 않도록 주의하고, 실행 단계에서 안전하게 불러오는 방식이 일반적으로 권장됩니다.

처음 강의에서 push.yaml을 workflows 폴더에서 part1으로 옮겼을때

안녕하세요 ~말씀하신대로, .github/workflows 디렉토리안에 github actions workflow (*.yaml) 가 정의되어야깃헙액션이 동작합니다. 말씀하신대로 워크플로우를 추가할 때마다 .github/workflows안에 추가해야 반영됩니다.이건 깃허브에서 정의한 규칙이라 커스텀하게 바꿀 수 있는 부분은 아닙니다. 아래 댓글 남겨주신 부분에 대해서도 답변드리겠습니다. 다른 사용자들도 테스트 할때 workflows안에 만들면 헷갈리거나 너무 많아서 정리가 쉽지 않을 것 같은데일반적인 사용 사례의 경우는 아래와 같습니다.워크플로우 테스트를 위한 브랜치 새로 생성해서 그곳에서 테스트를 완료한 후 코드 리뷰 과정 (PR)을 통해 추가하고 싶은 워크플로우를 반영합니다. (각 워크플로우마다 역할에 맞춰서 네이밍) 예시로 참고할만한 오픈소스 레포지토리의 워크플로우 링크입니다. https://github.com/aws/karpenter-provider-aws/tree/main/.github/workflows 여러 사용자가 하나의 브랜치에서 여러 워크플로우를 구성하고, 구성한 모든 워크플로우가 push 이벤트에 의해 트리거된다면 관리가 복잡해지는 경우가 생길 수 있지만 보통은 그런 경우보다 각 역할에 맞는 워크플로우를(다양한 이벤트 기반으로) 구성하고 각자의 브랜치에서 테스트 완료한 후 코드 리뷰 후에 반영되므로 관리의 복잡성이 큰 상황은 아닐 것 같습니다.

이벤트 트리거 pull_request의 types

안녕하세요 ~pull request 이벤트의 activity type으로 closed를 정의하는 이유는 PR이 merge되는 시점에 GitHub Actions 워크플로우를 트리거하기 위해서입니다. closed 이벤트는 PR이 닫힐 때 발생하며, 이때 PR이 merge되거나 취소될 때 모두 트리거됩니다. 따라서 PR이 완료된 상태를 확인하는 중요한 기준이 됩니다.closed 타입을 설정한 후, 아래와 같이 Job 레벨에서 조건을 추가하면github.event.pull_request.merged == true image-build: if: github.event.pull_request.merged == true runs-on: ubuntu-latest permissions: id-token: write contents: read steps: - name: checkout the code uses: actions/checkout@v4PR이 merge될 때만 워크플로우가 실행되도록 설정할 수 있습니다.만약 이렇게 Job level에서 if condition을 통해 제어하지 않는다면,PR이 merge or 취소되는 2가지 경우 모두 워크플로우가 실행될 수 있습니다.

강의자료 다운

안녕하세요, jyyun 님 방금 제가 수업 자료를 다운로드 받아서 확인해봤는데, 잘 확인됩니다.섹션1 강의소개에 강의자료 강의에서 오른쪽 상단 수업 자료 아이콘을 클릭하시면 다운로드가 정상적으로 동작하는데 다시 확인 부탁드리겠습니다.

cloud9 서비스 종료

안녕하세요 ~확인해보니 aws cloud9에 대한 서비스 종료가 있었네요 . 말씀하신대로, cloudshell을 사용하는 방법도 가능해요 .현재 시점에 테스트를 해봐야 더 정확한 답변을 드릴 것 같은데,제가 알기로 cloudshell 사용하는 상황이라면, 새롭게 ec2 인스턴스를 생성할 필요가 없고aws에 로그인할 때 사용하는 권한을 가지는 shell을 사용할 수 있는 것으로 알아요 . 만약 root 권한으로 로그인했다면, cloudshell 사용 시 루트 권한을 가진 shell을 사용할 수 있고그러면 강의에서 안내하는 IAM Role을 생성해서 붙일 필요 없이 바로 실행하실 수 있어요 . ec2 인스턴스를 새로 생성할 필요 없이, cloudshell에서 github clone한 이후에강의에서 진행하는대로 init script실행하고 eks cluster setup 한 다음에 그대로 진행해도 될 것 같습니다. cloudshell로 진행하실 때, 문제 생기는 부분이 있다면 댓글로 상황 설명 자세히 해주시면제가 확인해보고 명확한 가이드 드리겠습니다 !

시나리오2에서 여러 릴리즈 브랜치를 한 번에 운영환경에 배포

안녕하세요 ~질문 주신 내용이 제가 강의를 만들면서 많은 고민을 했던 부분입니다. 원래는 질문 주신 부분에 대한 내용을 강의로 만드려고 계획했으나, 많은 부연 설명과 복잡성 때문에 간략히 변경했습니다. 그래서 언젠가 질문이 오지 않을까 생각했던 내용인데, 이렇게 물어봐주셔서 신기하네요 ㅎㅎ 말씀하신 대로, 시나리오2는 추가되는 기능의 횟수만큼 운영환경에 배포되는 방식입니다. 시나리오2에 국한해서 답변드리기가 조금 어려워서 좀 더 내용을 확장한 상태여야 더 의미 있는 답변을 드릴 것 같습니다. 예시로 설명드리는 게 이해하시기에 더 나을 것 같아 아래와 같은 예시로 설명드리겠습니다.예를 들어, dev branch는 개발 환경, master branch는 운영 환경으로 구성되어 있고 처음 운영 환경에 배포된 버전이 v1.0.0이라고 가정하겠습니다. 이제 여기서, 적용해야 하는 기능 A, B 두 개를 적용해서 v2.0.0으로 운영 환경에 배포하려고 계획합니다. 이 경우, A와 B 기능을 각각 개별적으로 배포하는 것이 아니라 두 기능을 모두 포함한v2.0.0을 한 번에 배포하는 구조를 사용해보려합니다.보통은 이러한 과정에서, QA, Staging, Pre-production 등 다양한 환경에 A와 B 기능을 배포한 다음 검증을 통해 운영 환경에 배포하게 됩니다. 이제 이러한 내용을 GitHub branch와 Tag, 그리고 dev, QA, production의 개념을 조합해서 단계별로 설명드리겠습니다. dev branch에서 Feature/A 브랜치를 만들고 A 기능을 추가하고 dev branch로 PR 머지합니다.PR 머지되면 개발 환경에 A 기능이 배포됩니다 (이 시점의 커밋을 abcd라고 가정).배포가 완료되면 QA 환경으로 보내기 위해 release/v2.0.0-rc.1로 태깅합니다 (v2.0.0-rc.1 태그는 abcd 커밋을 가집니다). abcd 까지의 커밋을 가진 코드가 QA 환경에 반영되어 배포됩니다.이 때 v2.0.0-rc.1 태그와 동일한 커밋을 가지는 release/v2.0.0 브랜치를 최초 생성합니다.dev branch에서 Feature/B 브랜치를 만들고 B 기능을 추가하고 dev branch로 PR 머지합니다.PR 머지되면 개발 환경에 B 기능이 배포됩니다 (이 시점의 커밋을 efgh라고 가정).배포가 완료되면 QA 환경으로 보내기 위해 release/v2.0.0-rc.2로 태깅합니다 (v2.0.0-rc.2 태그는 efgh 커밋을 가집니다).efgh 까지의 커밋을 가진 코드가 QA 환경에 반영되어 배포됩니다.release/v2.0.0 브랜치에 v2.0.0-rc.2 커밋을 추가합니다.(그러면 abcd와 efgh 커밋이 이 release/v2.0.0 브랜치에 있는 상태가됩니다)QA 환경에서 배포 및 검증이 끝나면 release/v2.0.0 브랜치에서 master branch로 PR 머지합니다.master branch에 release/v2.0.0 브랜치의 커밋인 A와 B 기능이 반영되어 v2.0.0 의 기능이 배포됩니다.이 구조는 하나의 예시로 생각해주시면 됩니다. 또한, 위와 같은 방법 외에도 다양한 배포 전략을 고려할 수 있습니다.예를 들어, 여러 기능을 모아 한 번에 배포하려는 경우 기능 플래그(Feature Flag)를 사용하여 각 기능을 개별적으로 활성화하거나 비활성화할 수 있는 방법도 있습니다. 이렇게 하면, 기능을 개별적으로 개발하고 병합하더라도 운영환경에서는 필요한 기능만 선택적으로 활성화할 수 있게 됩니다.(Feature Flag 부분은 깃헙 액션으로만 하기 불가능합니다) 이 부분에 대해 강의로 담기가 쉽지 않아서, 간단한 시나리오로 변경했는데요 .내용을 쓰고 읽어보니 조금 난해할 수도 있겠다라는 생각이 들기도 합니다 ^^;;추가 질문이나 더 자세한 설명이 필요하시면 언제든지 말씀해 주세요. 감사합니다!

도커 볼륨 vs RDS, 롤백

안녕하세요 ~강의 커리큘럼을 넘어가는 부분도 있어서, 질문 주신 내용에 대한 답변이 정확하지 않을 수 있다는 점과텍스트로 설명드리기 때문에 쉽게 이해가 되도록 전달하기가 조금 어렵다는 점을 미리 말씀드리고, 답변 드리겠습니다. Q1. 개발 서버, QA, 스테이징 서버, 운영서버의 DB CI/CD는 현업에서 어떤 식으로 하나요?A1.제가 알기로 DB 관리에 CI/CD를 붙이는 케이스가 흔한 일은 아닙니다.보통 DB는 따로 관리하는 경우가 많은데 CI/CD 와 통합해서 관리하는 케이스는 제 경험상 아직 본 적 없습니다.요즘에는 data on EKS 라고해서 쿠버네티스 같은 컨테이너 오케스트레이션 환경에서 db를 운영하는 케이스도 있지만, 그 부분은 제가 잘 아는 부분이 아니라서 답변드리긴 어려울 것 같습니다.Q2. Docker volume을 사용하여 대량의 데이터를 관리하는 경우가 있는 지 A2. 도커로 데이터베이스 컨테이너를 운영하는 지 여부에 대한 질문으로이해했는데, 이런 케이스는 본 적 없습니다. Q3. QA브랜치에서 테스트를 통과하지 못하면 수정 브랜치를 만들어 개발서버에 다시 머지하고 테스트하나요?QA브랜치 뿐만 아니라 다른 브랜치에 오류가 생기면 바로 머지 할 지(hotfix처럼), 개발 브랜치에 머지 해 테스트를 다시 할 지 선택하는 건지 궁금합니다 A3.이 부분은 질문주신 내용에 대해 잘 이해를 못해서, 제가 이해한 부분까지만 답변드리겠습니다. 말씀주신 내용은 상황마다 그리고 어떻게 파이프라인을 구성했는지에 따라 조금 다를 것 같습니다.강의에서는 QA 브랜치는 따로 사용하지 않고, 개발 환경 배포에 성공하면 바로 태깅을 해서QA 환경으로 배포를 진행하는 방법으로 시나리오를 구성했습니다. 다른 브랜치에 오류가 생기면 이라는 의미를 그 환경에 문제가 생기면으로 이해하고 답변드립니다.문제가 생길 때 빠르게 조치하기 위한 작업을 진행할 때 hotfix 작업을 진행하게 되는데요.hotfix 작업을 어떻게 진행하는지는 케이스마다 다를 것 같아서, 아래는 참고용으로 봐주시면 될 것 같습니다.운영 환경 브랜치로 master branch를 사용하고 있다면 master branch 기반으로 새로 hotfix 브랜치를 만들고, hotfix 브랜치로 변경사항에 대한 커밋을 추가합니다.이 때 추가되는 커밋마다 테스트를 실행하고, 테스트도 통과되고 hotfix에 필요한 코드 수정이 완료되면hotfix 브랜치에서 master branch로의 PR을 머지해서 빠르게 운영 환경에 hotfix 코드를 반영합니다.이렇게 되면, 개발 환경에서는 hotfix 관련 코드가 없으니 운영 환경에서 개발 환경으로 다시 PR을 생성해서 머지하는 과정을 진행합니다. Q4.풀 리퀘스트가 거절되면 통합된 코드들은 어떻게 되는 지 궁금합니다. 항상 롤백이 되는 거라고 이해하면 될까요? A4.어떤 의미의 롤백을 말씀하시는지 제가 잘 이해를 못했습니다.PR이 머지되지 않고, closed된다면(거절) 해당 브랜치에 코드는 남아있게 되고배포는 진행하지 않게 됩니다.예를 들어, feature/123 에서 dev branch로 PR을 생성했는데 이 PR 이 closed된다면feature/123에는 커밋이 있지만 dev branch로 반영되지 않았으니 배포는 없고,feature/123 브랜치만 남아있게됩니다. 질문주신 내용들에 대해 최대한 답변드리려고 했습니다만, 답변하기 모호한 것들이 있어서명확하게 이해하시기에 어려움이 있을수도 있다라는 생각이 듭니다. 몇 가지 추가적인 정보나 구체적인 예시를 제공해 주시면 더욱 정확하고 도움이 되는 답변을 드릴 수 있을 것 같습니다. 필요한 부분에 대해 더 자세히 설명해주시면, 그에 맞춰 도움을 드리겠습니다. 감사합니다.

처음 push.yaml 에서 actions로 넘어갈때

안녕하세요 ~깃허브에서, 깃헙액션에 대한 업데이트가 자주 이루어져서 제가 강의를 진행할 때와조금 달라진 것 같습니다. 깃헙액션을 활성화 하기 위해서는, .github/workflows 라는 디렉토리를 만들고그안에 깃헙액션 파일을 정의하면 되는데요 이 부분을 참고해서 깃헙액션 워크플로우를 작성하시면, Actions 탭에서 활성화된워크플로우를 확인해보실 수 있을 것 같습니다.

일부 event는 디폴트 브랜치에서만 동작한다 ?

안녕하세요, 김형민님 말씀하신 것처럼, issue 이벤트는 디폴트 브랜치에서만 트리거되는 이벤트입니다. (사진 첨부: Note 부분)(사진)만약 아래와 같은 구조로 되어있다면, 정상적으로 실행되어야합니다.디폴트 브랜치 : pr-testpr-test 브랜치의 깃헙액션 워크플로우 : 트리거 : issue, 액티비티 타입 : opened 혹시 pr-test에 정의된 깃헙액션 워크플로우가 이 구조와 일치할까요 ?만약 pr-test에 issue 워크플로우가 정의가 되어있지 않았다면 실행이 안되기 때문에 이 부분을 확인해주시면도움이 될 것 같습니다.