CI(Continuous Integration)

2 minute read

CI에 대해 한번 다뤄보았습니다. github action에 대해서 간단하게 적을 수 있을거라 생각했는데, 생각보다 내용을 더 자세하게 다루는게 좋을거 같다고 생각되어서 다른 글에서 githb action을 자세하게 다루고, 이번 글에서는 간단히 소개만 하도록 하겠습니다.

Why CI

개발자들은 여러 개발자가 팀을 이루어서 프로젝트를 진행하게 됩니다. Alice, Bob이 서로 간에 소통없이 자기가 담당하는 기능을 개발해서 6개월 후에 만났습니다. 이제 , 서로가 만든 코드를 프로젝트 main branch 에 병합을 할려 합니다. merge가 되지 않습니다. 서로의 코드가 충돌을 일으킵니다.

Alice, Bob : 무엇이 문제지??
Alice : 내 로컬에서는 잘 돌아갓어 .
Bob : 나도야 !!
둘은 서로의 코드를 비교합니다.
Alice : 뭐야, 나 이 함수 삭제 했는데 , 니 코드에는 이게 있네
Bob : 아니 !!!! 언제 삭제했어?? 나 이 함수 필요한데 !
Alice : 필요없으니까 삭제했지, 왜 안 물어봤어!!!???

이를 계속 반복해서 어떻게든 코드를 merge하게 됩니다. 이러한 상황을 가르켜 merge hell 이라고 합니다. 되게 , 옛날에 있엇던 일인데, 사실 저도 부스트캠프 2기 최종프로젝트를 하면서 이와 같은 현상을 경험했습니다. 이것을 방지할려면 어떻게 해야할까요? 기능을 작은 단위로 나누어 기능을 만들때 마다 주기적으로 main branch에 merge 합니다.

Alice (3줄을 작성후): 음, 잘 돌아가네 . main branch 에 merge해야지 .
Alice : Bob, 기능 추가 했어 . 코드 최신화해
Bob : 알았어 .(그리고는 , Bob은 main branch에서 code를 pull 해서 최신화합니다.)

이렇게 하면 코드는 항상 최신 버전을 유지합니다. (이러한 버전을 관리하는 것도 중요한데 , 이는 다른 글에서 다루도록 하겠습니다. ) .따라서, main branch에 merge를 할 때 충돌도 적게 일어납니다. “한번에 아프게 맞으면 회복이 안되니까 덜 아프게 많이 맞는다.” 이게 바로 Continuos Integration 입니다.

CI automation

Alice가 새로운 기능을 만드는 상황을 예시로 들어보겠습니다.

Alice : (3줄을 작성후)새로운 코드를 작성했으니 Mike 불러야겠다. Mike 이거 test좀 해줘 !!
Mike : Alice 코드 나한테 보내주면 test해줄게. 일단 코드를 build해야지
Mike : (Build 성공후) 음, Build는 성공했고 , 다음에는 unit test를 해야지 .
Mike :(Unit Test 실패) 실패했네 . 코드가 충돌 나는데 , 최근에 Alice랑 Bob이 이 코드를 수정했었네. 둘을 불러야겠따.
Mike :(이메일 ) To, Alice , Bob , 다른 팀원 : Alice,Bob의 코드가 충돌이 나서 test가 실패합니다.

이렇게 매번 build 하는 반복적인 과정을 자동화 시키면 반복적인 작업에 대한 시간을 줄일 수 있습니다. Server에 자동화 된 tool을 설정해서 새로운 코드를 작성하면 Build-Test의 과정을 자동적으로 진행하도록 합니다.성공하면 merge를 합니다. 이것이, 실패하거나 성공하면 팀원들에게 알람이나 이메일이 가도록 설정할 수 있을 것입니다.