테코톡 발표를 마쳤습니다. 2년 전 이맘때쯤, 국비 수강 과정중에 테코톡을 처음 접했었는데.. 그 트랙룸에서 제가 발표를 하는 날이 오다니 아직도 믿기지가 않네요. (정말? 내가? 왜? 우테코? 실화냐..) 영상으로 전해지던 우테코만의 분위기를 저도 경험할 수 있었습니다. 원하지만 이루어지지 않을거라 생각하며 그러나 또 원하는 ㅋㅋ 그런 마음이었는데 이런 날도 오네요.. 발표를 들어주시고 격려해주고 응원해주신 모든 분들 정말 감사드립니다. 더 많이 학습하고 준비해서 더 양질의 발표를 하고 싶었지만 그러지 못해서 정말 아쉬운 마음이 크고 실망스러운 생각입니다. 그러나 마쳤다는 기쁨이 너무 크네요 ㅋㅋ 준비할 땐 몰랐는데.. 끝나고 나니 정말 홀가분합니다.
팀 프로젝트를 진행하며 몹 프로그래밍, 페어 프로그래밍 등을 활용하고 있습니다. 이 과정에서 하나의 컴퓨터를 호스트로 두고 진행하게 되면, 공동 작업자의 기여가 깃허브에 나타나지 않는다는점이 아쉬웠습니다. 관련하여 케이의 https://kth990303.tistory.com/349 포스팅을 읽고 이를 쉽게 적용하기 위한 플러그인을 설치한 내용을 작성해봅니다. 공동 작업자 표시 예시 깃헙 커밋 내역에서 공동 작업자를 표시해주고 싶었습니다. 상대방의 캐리를 받아 작업을 진행했는데, 나의 컴퓨터를 호스트로 사용했다는 이유로 커밋 내역에 저만 기록된다는 점이 아쉬웠습니다. 위처럼 공동 작업자들을 표시해줄 수 있다면 공동 기여분에 대한 보다 명시적인 표시를 해줄 수 있어 페어 프로그래밍 이후 만족감이 더 높을 것..
팀 프로젝트를 진행하며 다음과 같은 요구사항이 발생했습니다. 1. 특정 워크스페이스 구성원인지 식별할 수 있어야 한다 2. 내부 구성원이라면 해당 사용자를 식별할 수 있는 정보를 확보해야 한다 이를 구현할 방법에 대해 탐색한 결과를 간단히 기록해봅니다 OAuth Flow OAuth Flow 를 이해하는 데에 시간이 많이 필요했습니다. 레벨2에서 인증, 인가를 학습하며 RFC 문서를 통해 인증 서버와 자원 서버를 구분하여 사용한다는 개념은 미리 습득해두었지만, 이를 하나의 사용자 관점에서만 접근했었기 때문에 미싱 링크가 존재했습니다. 사용자와 두 개의 서비스가 존재할 때, 서비스 A는 사용자에 대한 인증을 서비스 B에 의존하는 상황이라면 상호작용하는 대상이 셋이 되고, 이 경우에 대한 이해가 추가적으로 필..
2010년, 제즈 험블과 데이비드 팔리의 Continuous Delivery가 출판되었습니다. 그리고 같은 해에 Git Flow가 빈센트 드리슨에 의해 제안되었습니다. 2022년 1월 GOTO Conference 채널에 업로드 된 영상에서 데이비드 팔리는 Git Flow가 CI/CD 에는 어울리지 않는다고 이야기합니다. 해당 영상의 내용을 요약하며 왜 그러한지 이해한 내용을 기록해봅니다. David Farley 가 이야기하는 CI 어.. CI 그렇게 하는 거 아닌데.. 추측(guessing)이 아닌 확인(checking)을 해야 한다 Dave는 여러 개발자들이 함께 일하고 있는 시스템의 상태에 대해 공유된, 정확한 관점을 유지하고 배포하는 것을 CI 라고 이야기합니다. 이러한 정의에 입각해서 Dave는 ..
Git Flow 전략에 대해 알아본 내용을 정리합니다. 각각의 브랜치들이 왜 필요한지, 생애주기는 어떻게 되는지, 다른 브랜치들과 어떻게 상호작용하는지 알아보겠습니다. https://nvie.com/posts/a-successful-git-branching-model/ main 브랜치 생애주기 서비스의 탄생, 종료와 생애주기를 같이하는 브랜치입니다. 계속해서 유지되는 브랜치입니다. 필요성 최종적으로 고객에게 전달되는 내용이 관리되는 브랜치입니다. 즉, 운영 환경에 현재 배포되어 있는 내용입니다. 특징 시멘틱 버저닝 전략을 활용하여 버전 태깅을 합니다. 다른 브랜치와의 상호작용 develop : 서비스의 탄생 시점에 한 번 파생 개발된 기능을 병합하는데 사용될 develop 브랜치를 main 브랜치 탄생 ..
