테코톡 발표를 마쳤습니다. 2년 전 이맘때쯤, 국비 수강 과정중에 테코톡을 처음 접했었는데.. 그 트랙룸에서 제가 발표를 하는 날이 오다니 아직도 믿기지가 않네요. (정말? 내가? 왜? 우테코? 실화냐..) 영상으로 전해지던 우테코만의 분위기를 저도 경험할 수 있었습니다. 원하지만 이루어지지 않을거라 생각하며 그러나 또 원하는 ㅋㅋ 그런 마음이었는데 이런 날도 오네요.. 발표를 들어주시고 격려해주고 응원해주신 모든 분들 정말 감사드립니다. 더 많이 학습하고 준비해서 더 양질의 발표를 하고 싶었지만 그러지 못해서 정말 아쉬운 마음이 크고 실망스러운 생각입니다. 그러나 마쳤다는 기쁨이 너무 크네요 ㅋㅋ 준비할 땐 몰랐는데.. 끝나고 나니 정말 홀가분합니다.
팀 프로젝트를 진행하며 몹 프로그래밍, 페어 프로그래밍 등을 활용하고 있습니다. 이 과정에서 하나의 컴퓨터를 호스트로 두고 진행하게 되면, 공동 작업자의 기여가 깃허브에 나타나지 않는다는점이 아쉬웠습니다. 관련하여 케이의 https://kth990303.tistory.com/349 포스팅을 읽고 이를 쉽게 적용하기 위한 플러그인을 설치한 내용을 작성해봅니다. 공동 작업자 표시 예시 깃헙 커밋 내역에서 공동 작업자를 표시해주고 싶었습니다. 상대방의 캐리를 받아 작업을 진행했는데, 나의 컴퓨터를 호스트로 사용했다는 이유로 커밋 내역에 저만 기록된다는 점이 아쉬웠습니다. 위처럼 공동 작업자들을 표시해줄 수 있다면 공동 기여분에 대한 보다 명시적인 표시를 해줄 수 있어 페어 프로그래밍 이후 만족감이 더 높을 것..
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 브랜치 탄생 ..
팀 프로젝트를 진행하며 재밌는 경험을 해서 기록해봅니다 😃 모든 종류의 Slack Event는 하나의 URL로 전달된다 Since your application will have only one Events Request URL, you'll need to do any additional dispatch or routing server-side after receiving event data. Slack Evnt API 문서 Slack App을 워크스페이스에 설치하고 권한을 부여하면, 특정 상황이 발생할 때마다 이를 이벤트로 감지하여 Slack App에 설정된 URL로 이 정보를 보내줍니다. 가령 채널에 메시지가 전송되었다거나, 편집 혹은 삭제되었다거나, 심지어 이모지가 달린 것까지. 사용자에 관련해서는..
