대충 알았던 내용들
프로젝트를 혼자하든 팀원들이랑 같이하든, 나는 기능에 집중해서 만드는 것을 참 좋아한다. 그런데, 내가 마무리 하는 단계에 있어서, CI/CD, 아마존배포 등 이런것에 약하다. 왜냐하면, 항상 팀원들이 마지막 단계를 끌고가다시피했다. 무슨말이냐하면, 나는 무엇을 만들까에 대해서만 집중했지, 만들고나서 이것을 어떻게 해야할지에 대해 생각을 잘 못했다는 말이다. 그래서인지, 다른 것을 배울때보다 별로 신경도 안쓰게 되었고, 집중도 되지 않았다. 그래서 대충 뭔지에 대해서 안다. 이번 기회를 통해 깔끔하게 정리하도록. 이상.
굉장한 비유와 배움을 얻었습니다.
참고: https://itholic.github.io/qa-compile-build-deploy/
컴파일, 빌드, 배포의 개념 및 차이
-
나는 번역가이다. -> 나는 개발자이다.
-
출판사로부터 일을 하나 받았다. -> 고객이든 누구든 아무튼 누군가가 나에게 개발을 요청했다.
-
영문으로된 글을 한글로 번역하는 일이다. -> 고수준 언어를 저수준 언어로 기계가 이해할 수 있게 하는과정이다. 컴파일 과정이다.
-
출판사에서 번역된 글들을 적절히 엮어서 책으로 출판할 것이다. -> 이 과정이 빌드이다. (3. ~ 4.)
-
출판된 책들은 서점에 진열되어 팔릴것이다. -> 배포한다.
이것만 보고서 뭔가 이해가 갑자기 확 되긴 했으나, 그래도 뭔가 글로 제대로 머리에 넣어야할 것 같다.
- 컴파일: 사용자가 작성한 고수준 언어를 컴퓨터가 이해 할 수 있는 저수준 언어로 바꾸는 일
- 빌드: 컴파일된 코드를 실제 실행할 수 있는 상태로 만드는 일.
- 배포: 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치시키는 일.
- 컴파일을 포함해 war, jar등의 실행 가능한 파일을 뽑아내기까지의 과정을 빌드한다고 하기도 한다고 한다.
여기서 내가 프로젝트 하면서 들었던 이야기들이 있다. 빌드 자동화, 배포 자동화, 테스트 자동화?
자동화 하면 뭔가 공장에서 찍어내는 기계들이 생각이 나긴한다. 이것도 비슷한 내용일 거라는 생각이 들긴하지만~
반복되는 작업들
완성된 코드를 서버에 올리고 나서가 본격적으로 개발의 시작이라고 할 수 있다고 한다.
왜냐하면 사용자들이 앱을 사용하고나서 버그가 발견되고, 그것을 통해 개선사항이 등장할 것이고, 컴파일, 빌드, 배포등의 과정이 코드수정 후에 반복되어야 하기 때문이다.
이렇게 된다면 너무 비효율적이기 때문이다. 만약 서비스 중인 프로그램의 코드를 변경 한다고 할 경우에, 더 비효율적이다. 또한 이렇게 수정하고 난 코드가 잘 동작하는지 알기 위해서는 테스트 코드도 작성하고, 검증도 다시 한번 하면서 검토하는 등 많은 작업이 필요하다.
이러한 과정들은 복잡하고 사람이 하면 할수록 실수가 나올 수 있기 때문에
'자동화'가 만들어진것이다.
우리가 자주쓰는 깃 또는 깃헙.
여기다가 그냥 수정된 코드를 올려놓고 나머지는 자동으로 수행되는 것이다. 그리고 위에 과정들이 다 끝나면 자동으로 개발자에게 리포트해준다. 이 과정에서 어느 부분을 자동화 시킬 것인지에 따라 빌드자동화, 배포 자동화, 테스트 자동화 라는 용어가 붙은 것이라고 한다.
그 다음에 CI/CD라는 개념으로 가야한다. 왜냐하면, 자동화 이야기 하고나서 팀원들이 CI/CD하는 곳도 있다던데? 이러면서 다른 조 얘기 많이했다.
CI/CD란?
CI -> Continuous Integration
모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적방식의 단점을 해소하기 위해 나타난 개념. 개발을 지속적으로 하면서 코드에 대한 통합을 진행함으로써 품질을 유지하자! 라는 의미.
예)
팀프로젝트를 상상해보면, 팀원들과 나는 깃헙 주소를 각각 클론 받아서 작업을 시작했다. 그리고 나서, 각 깃헙 컨벤션에 따라서 중앙저장소에 코드가 올라간다. 그런데 만약 팀원들이 귀찮아서 안올린다면? 할줄 몰라서 안올린다면 ? (나 깃헙 아무것도 몰랐을때 저랬다...)
이렇게 된다면 나중에 빌드 배포 테스트 이 과정이 정말 최악이고 귀찮은 작업이 된다. 내가 경험해봐서 안다.
작업을 잘 나누어서 일정한 어느 섹션의 작업이 끝날 때마다, 코드에 대해 리뷰 하고 테스트해보고 점검하는 것이 더 효율적이다.
이렇게 하게 된다면, 나중에 최종적인 작업세션에 다다랐을때 보다 높은 퀄리티의 코드를 가질 수 있고, 버그에 대한 개선사항도 줄일 수 있다.
단점: 귀찮다. 모든 인간들은 미리 하는 것에 대해 귀찮음을 느낀다.
그렇기 때문에 이 부분에 대해서 자동화를 돌리면 어떨까 라는 생각에 나온 것이다.
CD -> Continuous Deploy or Delivery
소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 지속적으로 관리하자는 개념.
단순하게, CI의 연장선이라고 생각하면 된다.
완전한 설명: CI프로세스를 통해 개발중에 지속적으로 빌드와 테스트를 진행하고, 이를 통과한 코드에 대하여 테스트서버와 운영서버에 곧바로 그 내용을 배포해 반영하는 것이다.
CI (빌드 및 테스트 자동화) + CD (배포 자동화)
이것을!!!!
도와주는 솔루션들이 있는데 그것들이~
CircleCI, Travis, Jenkins, Github Actions 등등.
와 이제 뭔지 알게되었다.
