Git 기반의 애자일 개발 환경 구축 및 개발 프로세스 설명 / 고객과 소통하는 SW 유지보수 프로세스 구축 - 인베슘Atlassian 대한민국
Git 기반의 권장 개발 프로세스, 빌드 테스트 자동화, Docker 활용법, Pull Request 기반의 프로세스 및 권장 저장소 구성
실사례 중심의 SW 유지보수 프로세스 상에서 JIRA Service Desk, Bitbucket, Pipeline, Bamboo, Jira의 역할과 연결성 및 활용 방법
저는 핀테크 서비스 개발 프로젝트에 참여하여 CI 구축과 QA 자동화 부분 개발을 담당하였습니다.
프로젝트가 시작하면 수 많은 개발자들과 기획자 그리고 QA 들이 다투는 것은 빈번한 일상입니다..
바쁜 개발 과정에서 기본적인 로그인 함수의 구현을 계속해서 체크해야 하는 것은 매우 불편하고 번거롭죠.
Selenium과 Jenkins를 통해 다음과 같은 상황을 자동화하여 개발자들과 QA/기획자들간의 갈등을 줄이고자 합니다.
스크린샷 중 가린부분들은 현재 회사 프로젝트 유출 방지를 위한 것이니 너그러이 용서해주시길..
Git 기반의 애자일 개발 환경 구축 및 개발 프로세스 설명 / 고객과 소통하는 SW 유지보수 프로세스 구축 - 인베슘Atlassian 대한민국
Git 기반의 권장 개발 프로세스, 빌드 테스트 자동화, Docker 활용법, Pull Request 기반의 프로세스 및 권장 저장소 구성
실사례 중심의 SW 유지보수 프로세스 상에서 JIRA Service Desk, Bitbucket, Pipeline, Bamboo, Jira의 역할과 연결성 및 활용 방법
저는 핀테크 서비스 개발 프로젝트에 참여하여 CI 구축과 QA 자동화 부분 개발을 담당하였습니다.
프로젝트가 시작하면 수 많은 개발자들과 기획자 그리고 QA 들이 다투는 것은 빈번한 일상입니다..
바쁜 개발 과정에서 기본적인 로그인 함수의 구현을 계속해서 체크해야 하는 것은 매우 불편하고 번거롭죠.
Selenium과 Jenkins를 통해 다음과 같은 상황을 자동화하여 개발자들과 QA/기획자들간의 갈등을 줄이고자 합니다.
스크린샷 중 가린부분들은 현재 회사 프로젝트 유출 방지를 위한 것이니 너그러이 용서해주시길..
KGC 2014, 'Software Enginner in Test' in Game Development (Bluehole Studio)Sungmin Kim
Document presented at Korea Game Conference 2014.
Title is ''Software Enginner in Test' in Game Development' and sub-title is 'How can TERA verify too many scearios by automation ?'
블루홀 스튜디오의 김성민 입니다. 이번 Korea Game Conference 2014에서 발표한 자료를 공유합니다. 발표 주제는 'Software Enginner in Test' in 게임 개발 입니다.
3. 소프트웨어 개발의 어려움
• 비전공자라도 누구나 개발할 수 있어 보인다.
• 개발해 보면 실제로 사람마다 차이가 엄청 크다.
• 유지보수가 점점 더 힘들어진다.
• 같은 프로세스라도 결과가 다르다.
• 개발 방법론이 수백 가지는 넘는 것 같다.
• 이것 저것 해보지 않은 게 없다.
• 언제나 품질 때문에 고통스럽다. (고객의 비명소리가
여기저기서 들린다.)
• 아예 새로 작성하고 싶지만, 엄두가 안 난다.
• 주위에 제대로 소프트웨어를 개발하는 곳도 없고, 배울
곳도 마땅치 않다.
4. 소프트웨어 개발의 어려움
• 쓸 만 하게 키워놓으면 회사를 옮긴다.
• 도대체 문서화가 되지 않는다.
• 문서화가 되어도 품질이 낮거나, 유지보수가 안 된다.
• 제대로 테스트를 할 수 없거나, 테스트를 해도 품질이
보장되지 않는다.
• 기능을 하나 추가하면, 다른 기능이 동작하지 않는다.
• 고객 마다 하나씩 버전이 존재하고, 여러 벌의
소스코드를 유지보수 해야 한다.
• 개발 일정을 예측할 수 없다.
• 코드가 점점 더 스파게티가 되어 간다.
• 개발 경험이 조직에 습득되지 않는다.
5. 소프트웨어 개발의 어려움
• 고객사에서 생긴 문제의 상당수를 수정할 수 없다.
(재현이 불가능하거나 원인을 알 수 없다)
• 개발자마다 각기 다른 스타일로 코드를 구현한다.
• 언제 고객에게 전화 올지 몰라 가슴이 두근거린다.
7. 지난 시간의 시행착오와 경험
• 1999년 이후 시행착오의 연속
• 매년 새로운 시도와 조직학습의 반복
• 전혀 품질을 보증할 수 없는 수만 라인의
코드로부터 수백만 라인의 코드를 일정 품질
수준으로 관리할 수 있는 수준까지 도달
소프트웨어 개발의 멘토가 있었다면 2년
만에도 가능했을 것!
9. Triangle : 프로세스
• 하나의 업무를 달성하기 위한 단계별 행동
지침을 기술해 놓은 단위
• 개발 프로세스, 릴리즈 프로세스, 유지보수
프로세스
• 리뷰 프로세스, 코딩 룰, 릴리즈 정책…
• 시사점
• 일련의 업무를 정량화된 단계를 통해 일정한
수준의 품질을 가지는 소프트웨어를
개발하자는 관점
• 매우 중요한 관점! But, 전부는 아님
10. Triangle : 프로세스
• Software Engineering에서 바라보는
소프트웨어의 관점
• 일정한 수준의 정량적 지표를 만족하면,
누구나 개발하더라도 일정한 수준 이상의
소프트웨어 품질이 보장된다는 공학적 접근
방식!
• 그러나, 지난 30년간 공학를 통한 소프트웨어
품질향상은 크게 괄목할 만 하지 않음.
• 전체가 아닌 부분이라는 관점에서 접근하는
것이 중요!!
• Q) CMMI가 우리 제품의 품질을 보증할 수 있나?
11. Triangle : 사람
• SE에서 설명하지 못하는 부분
• Software의 복잡도가 높아질수록 공학적
효용성이 왜 떨어지는가?
• 왜 동일할 프로세스를 통해서 개발을
하더라도 사람마다의 결과물이 다른가?
• 균일 품질을 보장할 수 있는 개발 방법론이
존재하는가? too many methodology
• 구현 대상물의 복잡도가 증가하면 공학보다는
예술에 가까워지는 소프트웨어의 특성이
고려되어야 함
12. Triangle : 사람
• 훌륭한 멘토와 같이 일을 할 수 있는 환경
• 멘토 그룹의 feedback을 받을 수 있는 환경
• 깊게 문제를 고민할 수 있는 시간과 공간적 지지
필요
• 소프트웨어 개발은 생각의 크기와 깊이에 그
결과물이 달라진다는 철학적인 이해가 반드시
필요!
• 좋은 인력…(누가 모르나…)
• 지속적인 Training 필요
13. Triangle : 시스템
• 시스템 행동을 조직화 할 있는 환경
• 해당 조직이 우수한 인력, 탁월한 프로세스를
가지고 있다 하더라도 그것이 지속적으로
유지될 수 있는 환경이 없다면, 일정 시간
이후에 해당 경험들이 사라짐. 조직 경험이
남지 않음.
• 업무의 시작 순간부터 마치는 순간까지 특정
환경(업무 프로세스가 자동화되도록)에서 수행,
감시, Feedback 될 수 있도록 반드시 수립해야
함.
14. Triangle : 시스템
• 예) 버그의 수정
• Open->Assigned->Fixing->Reviewing-
>Feedback->Closing->Close
• 환경 수립)
1. 버그는 반드시 버그 시스템을 사용
2. 해당 단계를 거치 않고, 다음 단계로 갈 수 없도록
3. 각 단계별로 입력해야 할 정보를 미리 정리, 부족하면
진행하지 못하도록.
4. 메일을 통해 관리자가 내용을 감시 혹은 자동화
• 조직내 관련 업무의 모든 지식이 자동으로
남게 됨 조직 학습 능력의 진화
16. PAL (Process Asset Library)
• 기 정의된 제품 프로세스를 문서로 모아 놓은
라이브러리.
• 기본적인 프로세스 정의 프로세스부터 세부 업무
프로세스를 차트화해서 관리
• EPG(Engineering Process Group)를 통한 프로세스
변경시 반영 및 유지
• 모든 조직 구성원들이 쉽게 찾아보고, 학습할 수 있는
공간으로서 활용.
• 없다면?
• 정의된 프로세스의 명문화된 저장소가 없음
모두가 암묵지화.
17. EPG 필요
• EPG : Engineering Process Group
• 전사 프로세스를 정의하기 위한 상위 프로세스 조직
• 프로세스 Stake Holder의 대표자가 참석
• CTO, 본부장, 리더급
• 사내 프로세스 이슈에 대한 토론 및 결론
• EPG 가 없다면?
• 프로세스 개선을 통한 업무 효율화를 위한 주체가
없어짐.
18. 정책
• 특정업무의 대원칙을 기술하고, 모든 구성원들이
따라야 할 의무를 지님.
• 암묵지를 형식지로 변환
• 예)
• 릴리즈 정책
• 개발 정책
• 유지보수 정책