인프런 커뮤니티 질문&답변
작성한 질문수
push로 자동으로 ec2로 빌드되고 갈아끼워지는건 이해했는데
작성
·
65
·
수정됨
0
현업에서는 그러면 누가 PUSH를 해서 CI/CD로 적용을 시키나요? 아무나 다 깃 푸쉬로 cicd를 적용하면 깃헙에 merge나 충돌이 날거같은데 그러면 막상 깃헙에 올라온 코드랑 ec2 올라가있는 코드가 다를거같은데 이 부분이 잘 안그려지네요... 질문이 두서가 없어서 죄송합니다 ㅠㅠ 어떤식으로 현업에선 흘러가는지 궁금합니다,.
답변 2
0
안녕하세요 Teo님! 질문 잘 해주셨습니다~~
main - develop - feature 브랜치를 활용해서 버전 관리를 한다고 가정하겠습니다!
크게 2가지 방법이 존재합니다.
첫 번째로, 각 개발자들이 feature 브랜치에서 특정 기능을 개발 완료한 뒤에
develop 브랜치에 직접 merge하기 위해 충돌을 해결하고 나서
Push를 하는 과정을 거치는 방식이 있습니다.
두 번째로, 각 개발자들이 feature 브랜치에서 특정 기능을 개발 완료한 뒤에
develop 브랜치에 직접 merge하기 위해 충돌을 해결하고 나서
Pull Request를 하는 과정을 거치는 방식이 있습니다.
2가지 방식 전부 다 '충돌 해결' 이후에 Push 또는 Pull Request 작업을 합니다.
강의에서 배우는 CI/CD 과정은 Push 또는 Pull Request 과정 이후에 작동하는 방식이므로
충돌 해결 과정은 사람이 직접 수동으로 진행할 수 밖에 없습니다:)
위 설명 중에 이해 안 되시는 점 있으시면 편하게 댓글 남겨주세요~~
안녕하세요 재현님! 개념적으로 확실히 잡아가시는 모습이 아주 좋네요 ㅎㅎ
“push 이벤트는 해당 브랜치에 커밋이 새로 생성될 때 발생한다.
따라서 충돌을 모두 해결한 뒤 생성되는 머지 커밋에 대해 CI/CD가 실행된다.”
→ 네 맞습니다! 정확히 이해하셨어요 !!
예를 들어 develop 브랜치에 push 이벤트를 기준으로
CI/CD가 트리거되게 설정되어 있다면,
머지 커밋이 develop에 올라가는 시점에 CI/CD가 실행되요 ~
즉, 충돌이 해결된 안정적인 커밋 기준으로만 배포되기 때문에,
코드 무결성을 보장할 수 있어요 !
"적어주신 내용을 보면 PR을 올리기 전에 dev와 충돌을 해결한 머지 커밋을 만들어야 한다고 이해됩니다. 후자의 방식이 현업에서 더 많이 쓰이는 방식인가요?"
-> 우선 "PR을 올리기 전에 dev와 충돌을 해결한 머지 커밋을 만들어야 한다"라는 의미는 아니에요 ~
두 경우 모두 "develop 브랜치에 merge하기 전에 충돌을 해결한다”는 의미일 뿐이에요 !
즉, PR을 생성하기 전이 아니라, PR을 머지(수락)하기 전"에 충돌을 해결하면 되는거죠 :)
현업에서는 Teo님이 지금까지 해오신 방법과 같이 PR을 먼저 올리 뒤,
충돌이 생기면 직접 해결하는 방식이 일반적으로 많이 쓰이고 있어요~
깃허브에서도 공식적으로 권장하는 플로우에요 :)
추가로 궁금하신점 있으시면 편하게 질문주세요~~😄😄
0
안녕하세요, 인프런 AI 인턴입니다. Teo님.
현업에서의 CI/CD 파이프라인 구현에 대한 질문을 주셨군요. 궁금해 하시는 사용 사례를 살펴보겠습니다.
현업에서의 CI/CD 활용 방식
브랜치 전략:
- 일반적으로 개인이나 팀 구성원은 자신이 작업하는 주제를 기반으로 브랜치를 만듭니다. 개발이 완료되면 이 브랜치는 테스트 및 코드 리뷰를 거쳐서 메인 브랜치에 병합됩니다.
- 각 브랜치에서 코드를 푸시할 때는 지속적인 통합(Continuous Integration)을 통해 자동으로 테스트가 실행되며, 이는 일반적으로 CI 서버(GitHub Actions, Jenkins 등)에 설정되어 있습니다.
- 일반적으로 개인이나 팀 구성원은 자신이 작업하는 주제를 기반으로 브랜치를 만듭니다. 개발이 완료되면 이 브랜치는 테스트 및 코드 리뷰를 거쳐서 메인 브랜치에 병합됩니다.
풀 리퀘스트(PR)와 코드 리뷰:
- 코드 변경 사항은 풀 리퀘스트를 통해 메인 브랜치에 병합됩니다. 이 때 코드 리뷰가 이루어지며, 여러 개발자가 코드를 검토하여 충돌을 해결하고 코드 품질을 향상시킵니다.
- PR이 승인된 후, 지속적인 배포(Continuous Deployment 또는 Delivery) 프로세스가 시작되어 프로덕션 환경에 배포될 수 있습니다.
- 코드 변경 사항은 풀 리퀘스트를 통해 메인 브랜치에 병합됩니다. 이 때 코드 리뷰가 이루어지며, 여러 개발자가 코드를 검토하여 충돌을 해결하고 코드 품질을 향상시킵니다.
자동화 및 충돌 관리:
- CI/CD 시스템은 충돌을 최소화하기 위해 자동화된 테스트와 통합을 제공합니다. 코드가 메인 브랜치에 병합되기 전에 자동 테스트가 실행되어야 하며, 모든 테스트가 통과된 경우에만 배포가 진행됩니다.
- 이는 깃에 잘못된 코드가 병합되는 것을 방지하고, 코드 상의 불일치(Conflict)를 줄이는 데 도움을 줍니다.
- CI/CD 시스템은 충돌을 최소화하기 위해 자동화된 테스트와 통합을 제공합니다. 코드가 메인 브랜치에 병합되기 전에 자동 테스트가 실행되어야 하며, 모든 테스트가 통과된 경우에만 배포가 진행됩니다.
실제 배포:
- 코드가 메인 브랜치에 병합되어 지속적인 배포로 EC2나 다른 서버에 배포되는 경우에는 이전 버전과의 호환성, 테스트 환경, 롤백 계획 등이 검토되어 안정적인 배포를 보장합니다.
- 코드가 메인 브랜치에 병합되어 지속적인 배포로 EC2나 다른 서버에 배포되는 경우에는 이전 버전과의 호환성, 테스트 환경, 롤백 계획 등이 검토되어 안정적인 배포를 보장합니다.
참고 자료
아래 링크를 통해 CI/CD 및 브랜치 전략에 대해 더 깊이 있는 정보를 얻으실 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변을 보다 궁금한 점 있어서 댓글 남깁니다.
댓글 내용 이해 확인:
push 이벤트는 해당 브랜치에 커밋이 새로 생성될 때 발생한다. 따라서 충돌을 모두 해결한 뒤 생성되는 머지 커밋에 대해 CI/CD가 실행되는 것이므로, 항상 실행 가능한 코드만 빌드/배포된다. 이렇게 이해하면 될까요?
Pull Request와 충돌 해결 순서:
저는 지금까지는 dev에 PR할 때, feat 브랜치에서 PR을 생성하고 충돌이 난 경우 직접 해결하는 방식을 사용했습니다. 하지만 적어주신 내용을 보면 PR을 올리기 전에 dev와 충돌을 해결한 머지 커밋을 만들어야 한다고 이해됩니다. 후자의 방식이 현업에서 더 많이 쓰이는 방식인가요?
감사합니다.