기성하다

Merge Merge란 무엇인가? - 서로 다른 작업을 하기 위한 별도의 공간을 생성할 때 브랜치를 생성할 수 있다. - 기능 구현을 위해서 해당하는 기능을 구현하기 위한 브랜치를 생성한다. - 기능 구현이 되는 경우 해당 기능을 main 브랜치에 merge한다 즉, main branch 내부에 브랜치를 본래의 브랜치로 합치는 과정을 Merge라고 한다. # 예시 과정 git checkout -b feature main // main에서 나오는 feature ... 기능 구현 git checkout main // main 브랜치로 작업 공간 변경 git merge feature // feature에 있는 변경 사항을 merge하여 가져옴 # 3-way-merge 아래에서 부터 main, docs, fea..

브랜치 전략이란? 여러 개발자가 협업하는 과정에서 git 저장소를 효과적으로 활용하기 위한 work-flow이다. 전략이 없다면 동료가 만든 브랜치나 배포, 혹은 테스트 브랜치를 구분하기가 어렵다. 브랜치 전략의 종류 1. Git flow : 2개의 main 브랜치와 3개의 보조 브랜치로 구성되어 있다. * 종류 1) main(master) : 제품으로 출시될 수 있는 브랜치 - 주기적으로 배포를 한다고 했을 때, 다음 배포할 내용까지만 main 브랜치에 저장한다. 2) develop : 다음 출시 버전을 개발하는 브랜치 - 배포를 하고나서도 개발을 진행을 해야 하는 상황일 때 해당 브랜치에서 작업한다. 3) feature : 기능을 개발하는 브랜치 (develop이 뿌리) - 찐으로 개발을 하게 되는 ..

사실 저번에 올렸던 CICD는 오류가 많은 설정이었다. 왜냐하면 CI를 못하기 때문이다. (테스트를 통과하지 못하는 코드라는 의미이다.) 언젠가 꼭 고쳐놔야겠다고 생각했는데 짬이 나서 코드를 좀 수정했다. 대체적으로 CI를 위해서 고민한 내용은 다음과 같다. 1. .env 파일을 어떻게 적용시킬 수 있을까? 2. Redis, MongoDB와 같은 기자재를 workflow 내에서 어떻게 연결시킬 수 있을까? 3. Test 용 서버를 만들고 싶은데 어떻게 배포할 수 있을까? 첫번째 이슈 .env 파일을 어떻게 적용 시킬 수 있을까? 1) 1차 시도 : actions>secrets 에 하나씩 넣는 방법 너무 비효율적이라고 느꼈음 심지어 yml 파일도 길어지기에 추가적으로 변수가 추가 될때마다 secret 키와..

Git Issue git issue를 쓰는 이유는 뭘까? 협업을 하다보면 항상 옆에 붙어있지는 않기 때문에 보다 빠르게 어떤 개발을 하였는지, 혹은 어떤 개발 이슈가 생겼는지, 버그가 생겼는지 공유하는 것이 중요하다. 하지만 수많은 git commit, push가 오가는 상황에서 해당 사항을 추적하기란 굉장히 어렵다. 그래서 git issue를 작성하고, 해당 issue 번호를 commit 메세지에 기입함을 통해서 해당 Issue와 관련된 commit 내용을 한꺼번에 볼 수 있다. 어떻게 작성할 수 있을까? 1. 레포지토리의 Issues에 해당하는 탭을 클릭한 후, New Issue를 선택한다. 2. 해당 이슈를 선택하게 되면, 설정해 놓은 템플릿이 나타나게 된다. 우리는 git commit 정책을 통해..

프로젝트를 할 때 언어적 특성이라던지, 기능의 특성이라던지...여러가지 문제로 서버를 다중으로 넣는 경우가 많다. 나도 그 문제에서 벗어날 수 없었고, 오히려 서브 서버가 fastAPI 였기 때문에 이제 spring Boot로 CICD를 구축하고자 한다. Spring Boot 의 CICD의 특징 사실 자바 파일은 모두 그렇겠지만, 배포를 할 시에는 jar나 war 파일로 배포하는 것이 통상적이다. 그 이유로 첫째는 용량 문제가 가장 크고, path 문제에서 벗어날 수 있다는 것이 가장 큰 장점이다.(사실 없으면 안된다 거지같은 루트 설정! 여전히 컨테이너 기반으로 할 것이고... runner 설정, 환경변수 설정 등 다양한 초기 과정은 앞서 블로그에 설명해놓았으니 이것을 참고해보면 좋을 것 같다. htt..

CICD란? 처음 간단한 코드를 배포하거나 수정하는 것은 그리 어려운 일은 아니다. 그러나 작성한 코드가 많아지면 여러 문제가 발생하게 된다. 1. 오류가 어디서, 언제 난 것인지를 확인하기 어렵다. 2. 배포를 했을 경우, 코드를 수정할 경우 다시 배포해야 한다. 배포라는 과정이 그리 쉬운 과정도 아니고, 오류를 잡는 것 또한 매우 짜증나는 일이기에 이런 것을 한번에 처리해줄 수 있는 자동화 기법이 필요하다. 그래서 등장한 개념이 CICD이다! CI : 지속적 통합으로, 코드를 통합할 때에 오류가 있는지 자동적으로 확인할 수 있는 것을 의미한다. CD : 지속적 배포로, 코드를 배포할 때 거쳐야 하는 여러 과정을 한꺼번에 처리해주는 것을 의미한다. git에서는 사실 CI는 pr을 보낼때마다 자동으로 진..

CI/CD를 활용하는 이유 - 간략한 설명 CI/CD란, continous integration/continous delivery로 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법이다. CI란, 지속적 통합을 의미한다. 많은 회사들이 병합데이를 설정할 만큼 branch를 병합하는 데 시간을 할애한다. CI는 변경 사항을 적용할 시점에 애플리케이션을 손상시키지 않도록 자동적으로 병합하는 것을 의미한다. 이때 새로운 의존성을 build하고, test하여 손상시키는지를 자동적으로 확인할 수 있으며 더불어 Merge까지 하는 것을 의미한다. CD는 CI의 과정을 통해서 나타나는 베이스 코드를 배포할 준비가 되어있도록 하는 것이다. 즉, 하나의 Repository에 적용..

Commit 과 Issue 번호 commit은 일종의 버전이라고 할 수 있다. 원하는 변경사항을 반영한 버전 관리라고 보면 쉽다. 해당 commit을 push를 진행하게 되면 실제 repository에 적용되게 된다. 이때 commit message를 대충 쓰는 경우가 많은데, 해당 메세지를 효율적으로 작성하는 방법을 생각해보자. 먼저 Issue 번호이다. 리포지토리 창에 Issue라고 적혀있는 부분이 있는데, 해당 부분은 해결해야 할 Issue를 작성할 수 있도록 해준다. 실제로 코드의 변경이 있거나 하지는 않지만, 해당 번호를 활용할 부분들을 차례대로 볼 수 있다는 장점이 있다. 실제로 위의 12번에 해당하는 Issue가 있는데, commit message에 #12가 붙은 경우의 history를 알려..

Git 을 처리하다보면 PR(pull request)를 많이 마주하게 되는데, 나도 몰래 Merge를 누르는 불상사가 나타날 수 있다. 이를 방지하기 위해 여러 명의 PR 승인이 있어야만 Merge가 가능하도록 Rule을 추가할 수 있다. 1. Repo에 Settings에 들어간다. 2. 우측바의 branch 카테고리를 누르고, add rule을 누른다. 이는 각 branch 마다 rule을 작성할 수 있다는 것을 의미한다. 3. 원하는 브랜치의 이름을 Branch name pattern에 작성하고 Require a pull request before merging을 선택하여, 세부 요건인 Require approvals를 선택하여 원하는 approvals의 숫자를 선택한다. 이와 같은 설정이 끝나게 되..