my-blog: CI/CD 워크플로우 복원 및 개선

요약

이전 커밋에서 삭제되었던 .github/workflows/ci.yml 및 .github/workflows/deploy.yml 파일들을 복원했습니다. CI 워크플로우는 Pull Request 시 백엔드 및 프론트엔드 코드 테스트를 자동화하며, Deploy 워크플로우는 master 브랜치에 머지 후 프로덕션 환경으로의 배포를 담당합니다. 총 162 라인의 코드가 추가되었습니다.

배경 및 목적

얼마 전 발생한 커밋(d7db458)에서 CI/CD 관련 워크플로우 파일들이 실수로 삭제되었습니다. 이로 인해 코드 변경사항이 자동으로 테스트되지 않고, 프로덕션 환경으로의 배포 또한 수동으로 이루어져야 하는 상황이 발생했습니다. 이는 개발 과정의 효율성을 저하시키고 잠재적인 버그를 프로덕션 환경으로 넘길 위험을 높였습니다. 따라서 이 문제를 해결하기 위해 삭제된 CI/CD 워크플로우 파일들을 복원하고, 필요한 경우 개선하여 안정적인 개발 및 배포 파이프라인을 재구축하는 것이 목적이었습니다.

구현 내용

가장 큰 변경 사항은 .github/workflows/ci.yml과 .github/workflows/deploy.yml 두 파일을 복원하고 내용을 재구성한 것입니다.

• .github/workflows/ci.yml:

  • 이전에는 존재하지 않았던 CI 워크플로우 파일을 새로 작성했습니다.
  • Pull Request가 master 브랜치로 제출될 때, 또는 workflow_dispatch를 통해 수동으로 실행될 수 있도록 트리거를 설정했습니다.
  • 백엔드(backend)와 프론트엔드(frontend)의 의존성을 설치하고, Playwright를 이용한 프론트엔드 빌드 및 E2E 테스트를 수행합니다.
  • 테스트 실행 중 데이터베이스를 백업하고, 테스트 후에는 복원하는 절차를 추가하여 테스트 환경의 일관성을 유지하도록 했습니다.
  • 테스트 실패 시 Playwright 리포트를 아티팩트로 업로드하는 기능도 포함되었습니다.
  • 총 124 라인의 코드가 추가되었습니다.

• .github/workflows/deploy.yml:

  • 마찬가지로 이전에 삭제되었던 Deploy 워크플로우 파일을 복원했습니다.
  • master 브랜치에 push가 발생하면 실행되도록 설정했습니다.
  • GitHub Environment "production" 설정을 통해 수동 승인 절차를 추가하여, 프로덕션 배포 전에 한 번 더 확인하도록 했습니다.
  • 승인 후에는 node3 서버에서 SSH를 통해 jcw@172.30.1.94 서버로 접속하여 deployment/redeploy.sh 스크립트를 실행하는 방식으로 배포가 이루어집니다.
  • 배포 성공 또는 실패 시 알림 메시지를 출력하도록 했습니다.
  • 총 38 라인의 코드가 추가되었습니다.

변경된 파일 목록

• .github/workflows/ci.yml
• .github/workflows/deploy.yml

추가/삭제 라인 수

• 총 추가 라인: 162
• 총 삭제 라인: 0

기술적 의사결정

이번 커밋에서는 특별한 기술이나 라이브러리 선택에 대한 의사결정보다는, 기존에 잘 동작하던 CI/CD 파이프라인을 복원하고 필요한 부분을 개선하는 데 집중했습니다. Playwright를 E2E 테스트 도구로 사용한 것은 이미 프로젝트에 도입되어 있었고, GitHub Actions를 CI/CD 도구로 활용하는 것도 표준적인 선택이었습니다.

다만, ci.yml 파일에서 테스트 데이터베이스 백업 및 복원 스크립트를 실행하도록 한 부분은 테스트 환경의 안정성을 높이기 위한 의사결정으로 볼 수 있습니다. 이는 매번 테스트가 독립적으로 실행될 수 있도록 보장하여, 테스트 간의 불필요한 의존성을 줄이고 일관된 결과를 얻기 위함입니다.

배운 점 및 개선점

이번 작업을 통해 CI/CD 파이프라인의 중요성을 다시 한번 깨달았습니다. 자동화된 테스트와 배포는 개발 생산성을 높일 뿐만 아니라, 코드의 안정성을 확보하는 데 필수적인 요소입니다.

• 배운 점:

  • CI/CD 워크플로우 파일의 중요성: 이 파일들이 삭제되었을 때 프로젝트 운영에 얼마나 큰 영향을 미치는지 직접 경험했습니다.
  • 테스트 환경 관리의 중요성: 독립적이고 재현 가능한 테스트 환경을 구축하는 것이 중요하며, 이를 위해 데이터베이스 백업/복원 등의 절차가 유용하다는 것을 알게 되었습니다.
  • GitHub Actions의 유연성: workflow_dispatch나 environment 설정을 통해 워크플로우를 유연하게 제어할 수 있다는 점을 배웠습니다.

• 개선할 점:

  • CI/CD 설정의 백업: 중요한 CI/CD 설정 파일들을 별도로 관리하거나, Gitignore에서 제외되어 있는지 확인하는 프로세스가 필요합니다.
  • Deploy 워크플로우의 상세 알림: 배포 실패 시 로그를 더 쉽게 확인할 수 있도록 알림 메시지에 관련 정보를 포함하면 좋을 것 같습니다.
  • 테스트 스크립트 최적화: 현재 테스트 실행 시간이 다소 길게 느껴질 수 있어, 향후 병렬 실행 등을 고려한 최적화가 필요할 수 있습니다.

• 다음 단계 계획:

  • master 브랜치로의 병합 시 자동으로 Deploy 워크플로우가 실행되는지, 그리고 프로덕션 환경에서의 수동 승인이 잘 작동하는지 실제 배포를 통해 검증할 예정입니다.
  • CI 워크플로우에서 발생하는 E2E 테스트 실행 시간을 측정하고, 필요하다면 테스트 코드 리팩토링을 통해 시간을 단축하는 방안을 모색할 것입니다.