Agile

새로 들어온 직장은 개발 프로세스에 Agile을 본격적으로  하고 있다.

전직장에서도 Agile로 개발을 하고 있었지만 막 시작한 단계여서 부분적으로 했었는데 새로 들어온 직장은 모.. Agile에 사활을 건거쳐럼 팔을 걷어 부치고 한다.

제일 인상적인건 Continous Integration을  새로 온 직장에서 하고 있는 방식인데, 그 규모가 내가 상상한 이상이다.

Continuous Integration을 하기위해서 대규모 Unit test혹은 Submodule test 인프라스트럭쳐를 공들여 잘 만들어 놓았다. 만일 개발자가 새로운 코드를 만들어 commit하면 자동으로 Unit test 혹은 Submodule test가 Trigger되고 전체 software 의 상태가 실시간으로 모니터된다. 물론 사람은 하나도 개입안된 상태로 자동으로..

이전 직장에서도 Unit test개념이 있었지만 모듈단위의 mock test가 주로 여서 모듈내부의 소프트웨어 로직 정도만 그것도 모듈담당자가 test에 정의한 부분만 했었는데 새로온 직장은 일단 test코드는 인도에 외주을 주고 제품 요구사항 정의할때 부터 test 계획이나 code를 모듈담당자 아닌 사람들이 만들고 있다.

또하나 놀라운건 Embedded제품은 서브모듈 test를 mock으로만 하기에는 모호한 경우가 많다. 예를 들면 STB는 HW가 Video decoding을 하는데, 실제 HW을 사용해서 test했을 때와  SW mock으로  test했을때 찾아낼수 있는 문제가 전혀 다르다.

그런데 여기는 Submodule test를 잘 define해서 실제 HW들을 사용해서 한다. 이게 그냥 개인 수준으로 1-2개 박스를 setup해서 하는게 아니라 큰 LAb에 엄청 많은 HW들을 설치해서 전체 인프로 스트럭쳐에다가 submoudle test용 HW farm같은걸 만들어 놨다.

이전 직장이나 삼성에서 일할때도 개발 과정에 제일 중요한 부분이 실제 HW를 이용한 test였지만, 이걸 잘 안하거나 test팀이 할때까지 기다리거나 하기때문에 시간이 지난다음에 여러 commits이 머지된 이후에  문제를 일으킨 commit을 모르는 상태로 debugging 할때가 많았었다.

그런데 여기는 이런걸 그냥 인프라스트럭쳐로 setup해 놨기때문에 개인이 신경쓰지 않아도 되고, 만일 내 code가 문제를 일으키면 바로 알수 있기때문에 바로 대응이 가능하다.

그리고 이렇게 모든 commit에 따른 전체 시스템 영향이 실시간으로 모니터링되고 문제가 있으면 빨리 고치기때문에 항상 동작하는 소프트웨를 release할수가 있다.

사실 여기는 만들어내는 software자체보다 그 software를 개발하는 Agile에 최적화된 인프라스트럭쳐가 더 중요한듯 하다.

하지만 이 시스템의 문제는 모든 변화에  대규모 인프라스트럭쳐가 연결되어 있기때문에 속도가 느릴수 밖에 없다. 좀 더 스피디한 변화를 원하거나 진짜 다 엎어 버리고 다시 시작하는 프로젝트같은건 하기 어려울듯 하다. 

그래서 인프라스트럭처를 서서히 변화시키면서 하는 점진적인 변화(Continous Integration)만 가능하다.

예전에 전시된 항공모함을 보고 놀란건 그 스케일이었다. 운동장만한...

새로온 회사에서 놀란것도 개발프로세스를 지원하는 인프라스트럭쳐의 스케일이다. 전체 시스템을 몇십분만에 test해주는..