환경 이름을 변경한다 #287
Description
변경되게 된 이유는 배포 방식의 변경때문. 하단 참고.
어떤 부분을 리팩터링하려 하나요?
그렇게 된다면 추가적으로 건의하고 싶은게 있는데요,
1/ 현재 stage 환경의 이름을 dev로 변경
기존에는 stage 환경이 "배포 직전 최종 점검"을 위한 공간이었기 때문에, release 브랜치와 연계되는 것이 자연스러웠습니다.
하지만 앞으로 release 브랜치를 없애기로 결정했기 때문에, 현재의 stage 서버는 "개발 진행 상황을 바로 보여주는 공간"으로 바뀔 것입니다.
따라서 stage 서버의 의미가 바뀌는 만큼, 이름도 dev로 변경하는 것이 더 명확하고 자연스럽다고 생각합니다.
ref. https://velog.io/@looljoon/%EA%B0%9C%EB%B0%9C%ED%99%98%EA%B2%BD-local-dev-stage-prod
2/ 현재 dev 환경의 이름을 local로 변경
지금은 개발자 개개인의 환경을 dev로 지정하고 있는데요,
stage가 dev가 된 만큼, 개개인의 개발 환경은 local 로 바뀌는게 좋을 것 같습니다!
AS-IS
dev : 개발자 개인의 환경
stage : release 브랜치로 CD되는 환경
TO-BE
local : 개발자 개인의 환경
dev : develop 브랜치로 CD되는 환경
작업 상세 내용
- 개발자 개인 환경을 local로 변경한다
- 현재 stage 환경을 dev로 변경한다
참고할만한 자료(선택)
슬랙 대화 아카이브
1.현재는 develop -> release(stage) -> master(prod) 로 구성되어 배포가 진행되고 있는데요
여기서 release(stage) 단계를 없에고 develop을 stage 단계로 사용하는건 어떨지 제안드립니다.
이는 develop 브랜치는 이미 작동가능한 코드만 merge되고 있기 때문입니다.
즉 이미 완전한 코드만 develop 브랜치에 존재하기에 자동으로 빠르게 stage에 배포해 검증하면 어떨까 싶습니다
2.그리고 2주에 한번은 master에 배포를 하는걸 목표로 해가면 좋을 것 같습니다
이런 제안을 드리는건 에자일 방법론과 빠른 배포에 따른 코드 부채 해소에 대한 글을 읽었기 때문인데요,
https://news.hada.io/topic?id=17820 -> 3번 코드 배포의 중요성
코드 배포의 중요성
코드 자체는 잠재적 부채이며, 배포되지 않은 코드는 가장 큰 부채임
테스트는 신뢰감을 주지만, 실제 배포는 진정한 승인을 의미함
배포 빈도가 높아질수록 호스팅 비용이 증가할 수 있지만, 최신 작업이 실제로 작동함을 확인하는 것은 중요한 이점임
에자일의 12가지 원칙(에자일은 조금 느낌이 다르긴 합니다)
3.2주에서 2개월 주기로 작동하는 소프트웨어를 자주 제공하되, 더 짧은 시간 단위를 선호한다.
stage 환경은 문제가 생겨도 괜찮은 환경인데요, 오히려 문제를 잡아내는 걸 도와주는 환경이라 생각합니다. 그렇기에 과감히 사용해서 빠르게 버그를 잡아내기 위해 develop 브랜치의 내용을 바로바로 따라가게 하는것을 제안드립니다!
단점으로는 바뀐 버전이 계속 바로 적용되기에 프론트엔드 stage 환경에서 활용하기 조금 불편해질 수 있고,
영서님이 stage 환경에 들어가기 전에 버그를 잡아주신 것 처럼
260dcbf
stage 환경에 들어가기 전 다시 검증하며 버그를 잡을 기간이 사라질 수 있습니다. 그러나 stage 환경은 문제가 발생해도 괜찮은 환경이라는 생각이 듭니다.
참고로 솔리드 커넥션 웹 개발에서는 main에 merge시 자동으로 배포되어 stage 환경에서 확인 가능하게 한 후, 태그 기반 배포를 사용하고 있습니다
https://github.com/solid-connection/solid-connect-web
https://blog.wibaek.com/entry/HeadVer-%EB%B2%84%EC%A0%80%EB%8B%9D-%EA%B8%B0%EB%B0%98[…]9E%90%EB%8F%99-%EB%B0%B0%ED%8F%AC-%EA%B5%AC%ED%98%84%EA%B8%B0
글 쭉 읽어봤는데 지금 방식의 불편함을 느꼈으니 바꿔도 좋을 거 같습니다!
처음엔 PR이 잦아지면서 깃허브액션이 너무 많이 작동할까봐 걱정했었는데,
사실 그렇지 않으니 바꾸면 이점만 있을 것 같습니다! 만약 문제가 생기면 그때 다시 이야기해도 좋을 거 같습니다!
먼저, 배포를 통해 더 빠르게 문제를 잡아내자는 의도에는 저도 깊이 공감합니다.
다만, 과거 경험을 돌아보면 몇 가지 우려도 함께 떠오릅니다. :thinking_face:
저는 우테코에서 프로젝트를 진행할 때, 위백님이 제안하신 것과 같은 방식으로 브랜치를 관리했었습니다.
당시에는 "개발 브랜치를 배포하면 더 자주 검증할 수 있지 않을까?" 하는 기대가 있었습니다.
하지만 실제로는 기대만큼 빠르고 유의미한 검증이 이루어지지 못했습니다.
제가 느꼈던 문제점들은,
1.develop 브랜치는 끊임없이 변화하므로, "머지않아 또 변경될 것"이라는 인식이 생깁니다.
2.다른 문제는 "기준의 부재" 였습니다.
develop 브랜치는 본질적으로 작업이 진행 중인 코드가 포함될 수밖에 없습니다.
따라서 개발 사이트가 정상 동작하지 않을 때도,
"이건 아직 작업이 덜 끝나서 그런 건가?", "아니면 실제 오류인가?"를 명확히 구분하기가 매우 어려웠습니다.
특히 프론트엔드와 백엔드의 작업이 항상 동시에 끝나지 않는 경우에 더 그러했습니다.
우리가 개발을 할 때는 백엔드 수정과 프론트엔드 수정이 시간차를 두고 진행되기 쉽습니다.
그러다 보니 웹사이트에서는 "어느 쪽이 덜 끝나서 오류가 나는지"를 판단하기 어렵고,
다른 쪽에 ‘작업이 다 완료된 상태인지, 진행 중인지’ 물어보기 위한 비용도 발생합니다.
3.develop 브랜치에는 계속 새로운 기능과 변경사항이 추가되므로, 무엇을 검증하려 했는지도 잊어버리기 쉽습니다.
정리하자면,
-웹사이트로의 검증을 통해 어떤 기능을, 어떤 목적을 가지고 검증해야 하는지가 불명확했습니다.
-이로 인해 검증 자체의 중요도가 떨어지고, 빠른 피드백 사이클이 제대로 작동하지 않았습니다.
그래서 솔리드 커넥션 프로젝트에서는 stage 단계를 두고 개발하면서, 이 방식이 훨씬 효과적이라고 느꼈습니다.
역설적이게도 "stage에 배포하지 않으면 제대로 동작하는지 알 수 없는 상황"이었기 때문에,
오히려 더 자주, 더 의식적으로 stage 배포를 하게 되었던 것 같습니다. 😅
물론 이것은 어디까지나 제 경험에 기반한 생각입니다.
그리고 단순히 'develop → main' 구조만 있다면 우려들이 현실이 될 수 있겠지만,
이런 문제를 예방할 수 있는 다른 프로세스가 마련된다면, 충분히 보완될 수 있다고 생각합니다.
무엇보다 위백님이 제안해주신 핵심은 "배포를 통해 더 자주 검증하고 싶다"는 점이잖아요?
그 취지에는 저도 진심으로 공감합니다!
그래서 위백님께 여쭤보고 싶은 것은,
제가 이야기한 우려 지점들에 대해 공감하시는지,
아니면 위백님이 보시기에는 문제가 없을 것 같은지,
혹은 떠오르는 대안이 있으신지도 궁금합니다.
우리 프로젝트는 회사 프로젝트가 아니기 때문에,
조금 시행착오가 있더라도 여러 방식을 직접 경험해보면서 배우는 것도 큰 의미가 있다고 생각합니다.
만약 위백님이 "develop → main" 구조가 더 빠른 배포와 검증을 가능하게 할 것이라고 생각하신다면,
저는 그 의견을 따라가겠습니다.
이번에는 저런 일이 발생하지 않을지 저도 궁금하기 때문입니다 😊
확실히 기준이 없다는 점이 공감이 되는데요, 그럼에도 저는 무조건 1 단위로 배포하는 것보다 0.1, 0.2씩 들어오는 것이라도 바로 배포되는 것이 프론트(웹사이트) 입장에서 개발하기 좀 더 편할것이라 느낍니다.
그리고 다음과 같은 이점을 얻을 수 있다고 생각합니다
stage 배포를 위한 PR의 번거로움이 줄어든다
형식적으로라도 현재는 RELEASE 커밋에도 코드 리뷰 형식을 갖추고 있어 지연이 생깁니다
그리고 stage 환경 직접 배포해주기... 약간 귀찮지 않으신가요? 저는 다소 그렇게 느꼈습니다
더 빠른 배포 주기 - 배포는 그 자체로 의미가 있다
최근 31개의 feature 커밋중 stage 커밋은 8개였습니다. 평균적으로 4개의 커밋마다 배포가 이루어진셈입니다
기능이 완성되지 않더라도 앱이 실행만 된다면 무언가 진전된것이고 배포되기에 충분하다고 생각합니다.
그리고 테스트와 더불어 정말 앱이 작동하는지, 버그가 있는지 확인하기에 가장 좋은 방법이라 생각합니다.
그리고 시행착오가 있더라도 한번 해당 방식을 검증해보고 싶네요:blush: