개발 프로세스

개발 프로세스란 소프트웨어 시스템이나 어플리케이션 개발 및 유지보수할 목적으로 수행되는 활동의 절차를 뜻한다. 개발 프로세스의 목적은 개발에 대한 전체적인 가이드라인을 제공하는 데에 있으며, 개발 절차 유무의 차이는 클 것이다.

소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, Software Develpment Life Cycle)를 기반으로 만들어졌다.

개발 프로세스의 단계

요구분석 및 시스템 명세 작성
문제분석 단계라고도 하며, 개발할 소프트웨어의 기능과 제약조건, 목표 등을 사용자와 함께 정확히 정의하는 단계. 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성한다.

설계
앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정한다. 크게 시스템, 프로그램, UI 설계로 나뉘며, 시스템 구조설계는 시스템을 구성하는 내부 프로그램이나 모듈간의 관계와 구조를 설계하고, 프로그램 설계는 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계한다. 이 중 UI 설계는 사용자가 시스템을 사용하기 위해 보이는 부분을 설계하는 사용자 인터페이스 설계에 해당된다.

구현
설계 단계에서 논리적으로 결정한 문제 해결 방법을 프로그래밍 언어로 실제 프로그램을 작성한다. 이 때 프로그래밍 기법은 두 가지로 나뉜다.
- 구조화 프로그래밍 : 조건문, 반복문을 사용해 프로그램을 작성하고 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현하며 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉬운 장점이 있다.
- 모듈러 프로그래밍 : 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법으로 모듈별로 개발과 테스트 및 유지보수가 가능하며, 모듈의 재사용이 가능하다는 장점이 있다.

테스트
개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확히 맞는지 검사하고 평가하는 일련의 과정이다. 미처 발견하지 못한 오류를 발견할 수 있어 매우 중요하다.

배포 및 유지보수
시스템이 인수되고 설치된 후(배포) 일어나는 모든 활동을 지칭한다. 이후 일어나는 커스터마이징, 구현, 테스트 등 모두 이 단계에 포함되므로 소프트웨어 생명주기에서 가장 긴 기간을 차지한다. 유지보수의 유형에는 네 가지가 있다.
- 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업
- 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업
- 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업
- 예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업

실제 개발에 착수하는 단계는 구현부터이다. 현재 그림 상에서는 이 단계들이 계속 꼬리를 무는 순환 구조로 되어 있지만, 실제 개발 환경에서는 환경에 따라 각각의 단계가 세밀하게 나뉘어져 있기도 하며, 각 단계가 계속 반복되기도 한다. 이처럼 개발 프로세스는 다양한 모델이 존재하며, 앱의 규모나 종류를 고려해 개발 모델을 선택한다.

전통적인 개발 프로세스

기존에 존재하던 개발 프로세스는 워터폴(Waterfall) 방식이 있다. 말 그대로 폭포처럼 단방향으로 프로세스가 진행되는 개발 과정을 뜻한다. 보통 아래와 같은 사이클을 가지며, 유지보수가 끝나면 다시 처음의 단계로 돌아가 시작하는 것이 가장 기본적인 모델이다. 여기서 변형된 모델들이 나오기도 하지만 보통은 프로세스의 추가나 세분화하는 수준에서 그친다.

이런 워터폴 개발 방식은 실제 출시 기한을 정해놓고 순차적으로 프로세스를 진행해 어플리에키션을 완성해 배포하기 때문에 실제로 배포되어 유저에게 전달되는 시간이 오래 걸린다. 또한 실제 디자인 또는 개발된 화면을 시각적으로 확인할 수 있는 단계는 이미 많은 단계가 지나온 시점이기 때문에 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정해야 하기 때문에 일정과 비용 등 많은 부분에서 애로사항이 발생한다. 따라서 대부분은 출시 시점에 소프트웨어의 신뢰성 및 안정성을 보장 받기 힘들며, 배포 직후에도 수많은 버그를 마주하게 될 가능성이 있다.

그래서 전통적인 소프트웨어 개발 프로세스에서는 소프트웨어의 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입하기도 한다.

시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인한다. 요구사항을 만족하지 않는다면 다시 요구분석 단계로 돌아가 새로 개발하기도 한다.

알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트하는 것으로, 주문형 제품의 경우 개발진과 클라이언트 사이에서 동의가 이루어질 때까지 수행된다. 대기업의 경우 이 업무를 주로 하는 전문 QA팀이 존재한다.

베타 테스트 : 고객의 실제 사용 환경에서 수행되는 테스트로, 미리 선별된 유저들이 해당 제품을 사용해보고, 이 과정에서 에러나 버그가 발견되면 수정하는 식으로 진행된다.

이런 전통적인 개발 프로세스에는 다양한 테스트 방식을 도입해도 결국 사용자가 항상 최신 상태로 업데이트를 해줘야 되고, 버그가 수정된 버전을 유저에게 즉각적으로 전달하기 어렵다는 한계가 존재한다.

모던 개발 프로세스

이런 기존 프로세스를 벗어나기 위해 만들어진 프로세스 중 하나가 애자일(Asile) 방식이다. 이 애자일 방식은 스프린트(sprint)라는 짧은 주기의 개발 사이클을 계속 반복한다.

이 방식은 요구사항이 변하는 것을 당연한 전제로 두고 있어 계획에 의존하여 형식적 절차를 따라야 하고 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 훨씬 효율적으로 개발에 착수할 수 있다. 애자일 개발 프로세스를 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능해지는데, 이런 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합하다.

SaaS?

SaaS는 클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식이다. 어플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리해 고객이 제어하거나 관리할 부분이 거의 없다. 따라서 사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번의 배포도 가능하고, 빠른 배포 속도를 보장 받을 수 있다.

전통적인 개발 프로세스 vs. 모던 개발 프로세스

	워터폴	애자일
장점	- 프로세스가 길고 순서가 잡혀 있으므로 팀의 규모에 상관 없이 따르기 쉬움 - 개발 주기가 정해져 있으므로 새로운 프로젝트를 안정적으로 시작 가능 - 요구 사항이 확정되어 있으므로 프로젝트를 실행하기 수월하며, 개발 목표를 자주 변경하지 않아도 됨 - 프로젝트의 전 과정에 필요한 예산 및 자원이 초기에 확정되어 예상 결과와 리스크를 통제하기 훨씬 쉬움	- 빠르면서 유연한 개발 과정 - 짧고 반복적인 스프린트로 구성되어 있어 품질에 초점을 맞출 수 있으므로 빠르게 결함을 인지하고 수정 가능 - 스프린트를 통한 짧은 반복 과정으로 개발 과정 중에 신속히 제품 변경 가능
단점	- 개발이 순차적으로 진행되므로 앞 단계가 완성되지 않으면 다음 단계로 넘어갈 수 없어 개발 속도가 느리고 유연성이 떨어짐 - 테스팅 단계에 이르러서 이슈가 발견되는 경우가 왕왕 있음 - 개발 요구 사항이 초기에 확정되므로 범위 변경이 자유롭지 못함	- 스프린트에 대한 경험이 있으며 빠른 반복 작업에 익숙한 스크럼 마스터가 필요함 - 고객이 수많은 변경 사항을 검토해야만 하는 번거로움 발생 - 팀원이 잘 조직되어 있지 않거나 자립성이 떨어지는 경우 애자일론을 채택할 시 문제가 발생
이런 상황에 적합	- 높은 예측 가능성과, 순차적인 프로젝트 타임라인, 사전 확정 예산이 필요한 경우 - 프로젝트 팀의 경험이 적은 경우 - 요구사항이 간단하거나, 타임라인이 긴 프로젝트를 수행하는 경우	- 요구사항이 간단하거나, 타임라인이 긴 프로젝트를 수행하는 경우 - 프로젝트가 완벽히 수행될 때까지 결과물을 기다리는 것보다 결과물에 대해 빠른 피드백이 필요한 경우
이런 기업 및 팀에 적합	- 개발상의 변경이나 리스크에 덜 민감한 기업 및 팀 - 제한적인 시간과 자원 탓에 협업이 자유롭지 못한 고객을 둔 기업 및 팀	- IBM, 시스코, AT&T, 마이크로소프트와 같이 크고 복잡한 회사들이 프로세스를 간소화해 변화에 더욱 신속하게 대응하고자 할 때 - 고객 및 외부 관계자와 정기적으로 긴밀한 협업을 수행하는 프로젝트 팀

DevOps

전통적인 IT 조직 구조로는 개발팀(Dev)와 운영팀(Ops)이 소프트웨어의 개발과 유지보수를 담당했다.

	Dev(개발팀)	Ops(운영팀)
특징	- 잦은 배포 및 업데이트 - 애플리케이션을 통해 새로운 기능(리소스)제공	- 프로덕션 앱의 안정성 확보 - 인프라 관리 - 모니터링 및 제어

개발팀이 잦은 업데이트를 통해 제품에 변화를 만들어야 한다면, 운영팀은 이런 서비스 구성의 변경을 최소화해 안정성을 확보하는데, 이 부분은 꽤 상충되는 부분이기 때문에 갈등을 야기한다. 이런 갈등이 빚어지는 구조는 현대 IT 시장에는 맞지 않을 뿐 더러, 제품의 릴리즈 주기를 길어지게 만든다.

그래서 탄생한 개념이 DevOps인데, 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어이다. 소프트웨어를 자주, 빨리 그리고 안전하게 배포하는 것을 목표로 애자일 개발 프로세스를 기반으로 한다.

DevOps 문화

DevOps는 특정 업무나 부서가 아닌 일종의 개발 문화이다. 만약 서비스가 중단된다면 누구든지 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야 한다. 이를 위한 기술과 지식이 제공되기 위해서 훈련과 효과적인 협업체계를 마련하는 것이 매우 중요하다. 실제 실무에서는 업무의 분리를 위해 DevOps팀을 따로 구성할 수도 있다.

DevOps 특징

DevOps는 개발에서 운영까지 하나의 통합된 프로세스로 묶어내고 사용하는 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고 일련의 작업들을 자동화한다. 즉 코드 통합, 테스트, 배포 과정을 자동화 시키는 것이다. 이 부분은 지속적으로 유지할 필요가 있는데, 지속적 통합 및 배포(CI / CD)라고 하며 DevOps의 핵심 원칙이라고 해도 과언이 아니다. 잘 구축된 CI / CD는 어플리케이션의 배포 시간을 크게 단축시킨다.

DevOps 사례

실제 인터넷 상에서 스트리밍이나 사진같은 많은 트래픽과 다양한 사용자 환경 및 요구에 빠르게 대응하기 위해 배포가 많은 기업 중 DevOps를 활용해 성공한 기업들이 많다.

실제 사례
미국 최대 온라인 스트리밍 서비스를 제공하고 있는 넷플릭스(Netflex)는 2012년 기준으로 3천만 명이 넘는 가입자를 보유하며 엄청난 스트리밍 트래픽을 아마존 웹 서비스(AWS)에서 10,000여개 이상의 인스턴스를 10여명 정도의 Devops팀으로 관리하고 있다.
사진 SNS 서비스로 야후에 합병된 Flickr는 초당 40,000 장의 사진이 업로드 되는데 Devops를 통하여 모든 배포 및 운영을 자동화하여 하루에도 10여 번 씩 이상의 배포를 한다.
음악 스트리밍 서비스로 최근 각광을 받고 있는 Spotify도 강력한 Devops 개발문화를 갖추고 오픈소스 도구를 활용하여 배포와 운영을 자동화하여 관리한다.

CI/CD

CI/CD는 약어로, 몇 가지 다른 의미를 가지고 있다.

CI
CI는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다. CI를 성공적으로 구현할 경우 어플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 어플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

CD
CD는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. 두 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때론 얼마나 많은 자동화가 이루어지고 있는지 설명하기 위해 별도로 사용되기도 한다.

CI/CD의 단계

일반적인 앱의 개발 및 유지보수 단계는 아래와 같다. 여기서 지속적 통합 및 지속적 전달을 단계별로 꾀할 수 있다.

지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계에서 꾀할 수 있다.

Code : 개발자가 코드를 원격 코드 저장소에 push하는 단계

Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계

Test : 코드 빌드 결과물이 다른 컴포넌트와 잘 통합되는지 확인하는 과정

이 과정에서 개발자는 코드를 잦게 원격 코드 저장소에 push하고, 테스트 및 빌드를 하며 빌드 결과를 통해 빌드의 성공 여부를 확인하고 통합 테스트 결과를 통해 개선 방안을 찾는다. 이 과정을 통해 개발자는 버그를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대한 빠른 전달이 가능해지며 지속적 배포가 가능해진다.

지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작한다. 모든 개발팀이 코드의 변화를 확인할 수 있어 투명하게 문제점을 파악할 수 있고, 또한 잦은 풀 리퀘스트와 머지로 코드를 자주 통합한다. 이 때 기본적인 테스트도 작동시킬 수 있다. 이런 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 자주 테스트 해볼 수 있다.

지속적 통합으로 보안 이슈, 에러 등을 쉽게 파악할 수 있어 해당 이슈를 빠르게 개선할 수 있다. 이전에는 각자 개발자가 작성한 코드를 합치고 난 후 모두 모여 빌드를 시작하고 나서야 문제점을 파악할 수 있었지만, 지속적 통합이 적용된 개발팀은 코드를 머지하기 전 이미 빌드 오류나 테스트 오류를 확인하여 훨씬 더 효율적인 개발을 할 수 있게 된다.

지속적 배포(Continuous Delivery/Deployment, CD)

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다. Release - Deploy - Operate 단계에서 꾀할 수 있다.

Release : 배포 가능한 소프트웨어 패키지를 작성한다.

Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출하는 실질적인 배포 부분이다.

Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지한다.

지속적 배포의 경우 코드 변경 사항의 병합부터 프로덕션에 적합한 빌드 제공에 이르는 모든 단계로 테스트 자동화와 코드 배포 자동화가 포함된다. 이 프로세스를 완료하면 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 배포할 수 있어 운영팀이 보다 빠르고 손쉽게 어플리케이션을 프로덕션으로 배포할 수 있게 된다.

최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있다.

지속적 배포의 대표적 사례 : Github Page

지속적 배포의 가장 흔하면서 대표적인 사례가 Github Page이다. 지정해둔 디렉토리에 정해진 방식에 따라 잘 커밋하기만 하면 Github Page가 알아서 해당 index.html 파일과 해당 디렉터리에 있는 파일을 잘 번들링해 Github Page 서버에 업로드한다. 이렇게 자동으로 인터넷에 배포가 되고, 만든 결과물을 쉽게 공유할 수 있게 된다.

CI/CD의 영역

CI/CD는 지속적 통합 및 지속적 제공의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있다. 지속적 서비스 제공은 지속적인 배포 과정까지 포함되는 방식으로 사용 되기도 한다.

결과적으로 CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 어플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미한다. 이 용어는 사례벌로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다.

배포 자동화

배포 자동화는 한 번의 클릭 또는 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 뜻한다. 배포 자동화는 수동적이고 반복적인 과정을 자동화해 시간을 절약하고 휴먼 에러(Human Error)를 방지할 수 있다. 배포 자동화를 통해 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계해 휴먼 에러 발생 가능성을 낮출 수 있다.

CI/CD 파이프라인

잦은 배포 과정을 자동화시키는 방법을 구축하는 것을 CI/CD 파이프라인이라 한다. 위의 그림처럼 개발자가 코드를 원격 리포지토리에 올리면 그 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포 서버로 전달된다. 배포 서버에 도달한 빌드된 코드는 어플리케이션 서버로 최종 배포가 완료되고, 그 결과물을 유저가 직접 확인하게 된다. 여기서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지이다. 이 부분을 지속적인 통합 및 배포를 위해 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

기본 단계와 수행 작업

배포에서 파이프라인(Pipeline)이라는 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다. 파이프라인은 전체 배포 과정을 여러 단계(Stage)로 분리하는데, 각 단계를 파이프라인 안에서 순차적으로 실행되며 각 단계마다 주어진 작업(Action)들을 수행한다.

Source Stage : 원격 저장소에서 관리되고 있는 소스 코드에 변경 사항이 일어날 경우 이를 감지해 다음 단계로 전달하는 작업을 수행한다.

Build Stage : Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공하고 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.

Deploy Stage : Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

파이프라인의 단계는 필요에 따라 더 세분화하거나 간소화될 수 있다. DevOps를 전문으로 학습하는 경우 단계를 세분화해서 나누기도 하며, 해당 툴을 소개하는 업체에 따라 용어를 미묘하게 다르게 사용하기도 한다.

구성요소 및 장점

빌드 (소프트웨어 컴파일)

테스트 (호환성 및 오류 검사)

릴리스 (버전 제어 저장소의 애플리케이션 업데이트)

배포 (개발에서 프로덕션 환경으로의 변환)

규정 준수 및 유효성 검사

이 과정이 실무에서는 반복적인 프로세스이기 때문에 이 부분을 일련의 자동화 단계로 만든다고 볼 수 있다. 이렇게 구축된 파이프라인은 최신 버전의 어플리케이션을 업데이트하고 제공하는 일련의 처리 단계에서 소요되는 시간을 수동 작업에 비해 더 빠르고 안정적이며 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높여준다.

Github Actions

Github Actions은 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화 할 수 있는 CI/CD 플랫폼이다. 레포지토리에서 pull request나 push같은 이벤트를 트리거로 Github 작업 워크플로를 구성할 수 있다. 워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.

워크플로는 YAML ( .yml 혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있으며, 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치한다.

비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이 제한되어 있지만 공개 레포지토리는 무료로 사용 가능하다.

Github Actions 실습 : 배포 자동화하기

배포를 자동화 하기 위해서는 앞서 말했듯 .yml파일에 절차를 진행할 워크플로를 작성해야 한다. 기본적인 내용이 대부분 담긴 파일이 제공되었고, 파일의 구조를 분석한 뒤 실제로 실행했다.

name: client # 실행할 액션의 이름

# 액션이 실행되는 조건(이벤트)
on:
  push:
    branches:
      - reference # referece 브랜치에 push가 생길 때 실행된다.

# 액션 워크플로
# 워크플로의 이름을 key로 지정한다. 여러 개의 워크플로가 들어갈 수도 있다.
# 각각의 jobs는 독립된 환경(인스턴스)에서 실행된다.
# 병렬 처리가 가능해 효율을 높일 수 있다.
jobs:
  build: # job의 이름
    runs-on: ubuntu-20.04 # 액션을 실행 할 OS 지정
    steps: # 인스턴스에서 실행 할 각 절차
      - name: Checkout source code. # Github Checkout Action : 레포지토리에서 코드를 내려받는다.
        uses: actions/checkout@v2
      - name: Install dependencies # npm package install
        run: npm install
        working-directory: ./my-agora-states-client # 경로를 지정할 수도 있다.
      - name: Build # react build 실행
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION # 기본적으로 설치된 AWS CLI의 버전 확인
        env: # 레포지토리의 secret을 이용해 env로 지정할 수 있다.
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws --version
      - name: Sync Bucket # AWS S3 버켓에 Build된 파일 업로드
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-64-ninefloor-s3 \
            --delete
        working-directory: ./my-agora-states-client

⚠️ Issue : S3 버켓 싱크 중 에러 발생

액션 실행 중 The user-provided path dist does not exist.라는 메세지와 함께 오류가 발생했다. 해당 스텝에서 나는 원래 working-directory: ./my-agora-states-client/build로 작성했는데, 오류 메세지를 찾아보니 해당 디렉토리를 찾을 수 없다는 내용이었다. 페어분은 /build 부분을 제외했을 때 정상적으로 작동했다 하셔서 동일하게 진행했고, 나 역시 그렇게 변경하고 나니 정상적으로 실행되었다.

Why?
AWS CLI에서 입력할 수 있는 s3 sync 명령어의 기본 형태는 아래와 같다.
```
aws s3 sync /<ORIGIN_PATH> /<TARGET_PATH>

# .yml에서 작성한 실제로 실행 될 명령어
aws s3 sync --region ap-northeast-2 build s3://fe-64-ninefloor-s3 --delete
```
기본적으로 올라갈 파일의 경로와 버킷의 경로를 작성해주는데, 위의 명령어를 보게 되면 이미 build로 올라갈 파일의 경로를 작성했기 때문에 워킹 디렉토리에 /build를 작성해주면 결과적으로는 ./my-agora-states-client/build/build 경로에 대한 업로드를 시도했던 것이다.

Action 실행 완료 및 결과

React App

my-agora-states-client in React

http://fe-64-ninefloor-s3.s3-website.ap-northeast-2.amazonaws.com/

Uploaded by N2T

티스토리툴바

CI / CD (배포 자동화)