개발 프로세스 향상은 주로 다양한 개발방법론에서 언급되며 해당 개발 방법론을 별도로 학습한적은 없습니다.
다만 다양한 개발 프로세스 개방 방법론에서 언급되는 기능들은 유용합니다.
지라의 선택이유는 실제 이것을 잘 활용하는 개발팀 내에서 무의식중으로 사용했기때문에, 익숙하기때문이고
다시 설치한 이유는 이론적인 서적보다, 실제 왜 그렇게 사용했는지? 경험을 바탕으로 다시 정리하기 위함입니다.
지라는 이러한 고민을 오랫동안 해온듯 하고 올바른 툴을 통한 개발 프로세스 확립은
다른 오픈 소스진영의 플랫폼에서도 지원이 될것으로 추측합니다.
생성된 티켓(Task)을 통해서만 개발(브랜치생성) 가능
PMS 티켓이 없으면, 개발일을 하지 못하게 하는건 아주 단순하고 강력한 프로젝트 관리방법입니다.
실제로 최고 관리지침이 갑자기 내려왔습니다. 티켓없이는 그냥 놀아라~
이것은 티켓없이 개발이 진행되고, 빌드관리자의 수동반영 경고를 무시하고 운영에 반영하는
고약한 문제를 인지한 상위관리자가 내린 지침이였습니다.
처음에는 혼란이였습니다. 자신이하고 있는 일을 적어도 명시적으로 타이틀화를 해야했으며
타팀의 문의에 대한 처리도(사소한 문제라고 생각한부분) 티켓을 통해 명시화 해야했습니다.
우리가 하고있는 일을 명시화함으로 잘못된 일을 알아가기 시작했습니다.
작은 문의가 구두로 통해서 전달이 되면 왜곡될수 있으며 그 왜곡된 사실이 타팀의 개발에 반영이
된다란것입니다. 이것은 설계문서가 약할뿐더러 설계문서와 코드가 일치하지 않는 본질적인 문제에서
시작한 문제이며 MBD(ModelBaseDesign) MDD(Model Driven Development)를 사용해서 해결의
실마리를 찾으려는 노력으로 연결이 되며 이것만 관리하고 개선하는 아키텍트가 생겨나게됩니다.
핫픽스라할지라도 생성된 티켓의 브랜치를 생성통해 작업이 진행되어야 하며 사소한 개선 변경역시 포함됩니다.
개발티켓에서 브랜치를 직접 생성할수있으며 부가적으로 전체 프로젝트 스케쥴및 배포관리등을 유기적으로 할수 있게됩니다.
분기점(브랜치) 만들기를 수행했을때 작동되는 UI
|
|
|---|
코드리뷰 코멘트에대한 대응으로, 피드백 교환및 바로 개선작업을 만들수가 있습니다.
Git에서 직접 브랜치를 생성하고 작업을 시작하면 해당 작업이 프로젝트 관리에서 제외될수가 있습니다.
PMS를 통해 진행된 작업은 빌드툴(밤부)에 연동되어 개발장비 자동반영가능하며 -보통 브랜치 빌드
배포여부를 통해 QA 진행도가능합니다. ( 배포자동화로 잠수함 패치 방지 )
여기서 품질향상은 진행된 티켓을 통해 코드 개발코드 리뷰 과정도 포함될수 있습니다.
최종 운영 배포는 별도의 운영반영티켓 생성후 최종 머지된 Master 소스를 운영 배포 전략 소스로 잡게됩니다.
운영배포 티켓은 운영에 반영되는 만큼 다음과같은 엄격한 조건을 걸수가 있습니다.
- QASignOFF가 나지 않는 운영배포는 실행되면 안됨
- 처리하지 못한 몇가지 이슈가 남아 있을시, 연기가되거나 최고책임자의 조건부 승인이 필요함 -처리하지 못한 이슈를 은닉하고 서비스에 반영될시 그책임은 개발자가 지기때문입니다.
- 배포순서에의해 문제가 생길수 있기때문에 배포절차를 명시적으로 언급해야하고 롤백계획도 수립해야함 -롤백 계획이 없다고 실제로 거부한 케이스도 있음
- 환경설정변경 의존 라이브러리 수동설정등이 있을시 언급이되어야하고 빌드책임자의 승인거부항목으로 자동화에대한 고민이필요함
- 도메인에따른 SSL설정의 중앙화(IIS에서 SSL을 위한 443Port Listen을 하지 않음), DB암호 설정의 중앙화(개발자는 운영 DB의 암호를 알면안됨),운영장비 어플리케이션 설정의 빌드툴에 분리화(Ex>각종 IP설정및,튜닝요소)를 소스에서 분리함으로 개발자에의한 수동설정에대한 이슈해결가능
- 소스 빌드 자동외에 외부 라이브러리 관리를 넥서스라는 중앙 자료실에서 관리하여 빌드툴과 연동됨 어떠한 새로운 라이브러리를 사용하기위해서는 해당 라이브러리 사용의 검증과 승인이 필요함
자동반영이 준비안되고수동반영으로 운영에 반영을 했을시점, 빌드관리자는 항상 해당 반영의 승인을 거부하였습니다.
하지만, 약속된 날자에 프로덕트(운영) 반영이 필요했기에 프로덕트 관리자의 조건부 추가 승인이 필요했으며
위와같은 승인 절차가 있었기에, 모든 운영에 반영되는 사소한 프로젝트조차 배포및 실행 자동화가 되었습니다.
티켓을 통해 문서화 추적기능
프로젝트 메니져(지라) 에서 문서를 언급을 하던지?
문서(위키)에서 관련 티켓을 언급하던지? 둘중하나를 하면 쌍방 연결이됩니다.
문서화과정이 개발과정과 분리된게 아닌 동시에 진행되고 포함되어야 항목입니다.
지라 티켓에서 언급된 문서
위키(문서화)에서 연결된 지라 연결
스프린트 관리
작업을 스프린트(1~3주간단위)단위로 지정하고 관리를 쉽게할수 있습니다.
스프린트는 한달이상의 계획으로 밀린 문서화와 테스트 품질향상을 마지막에 몰아서 하는 리스크를 줄이기위함입니다.
개발 배포단위를 작게 나눠 개발-문서화-배포-TEST를 지속적 진행하여 작은단위로 통합하는게 목표이며
배포자동화툴-QA및 개발이슈를 관리하는 프로젝트관리툴 -소스관리툴-문서화툴 등이 아주 잘 연동이 되어야합니다.
이렇게 진행된 티켓들의 리포팅은 자유롭게 자동생성가능합니다. (별도의 리포팅기능이 있으나, 위키에서도 동적으로 언급 가능합니다.)
스프린트 없음은 스프린트에의해 관리되지 않고 처리된작업입니다. |
|
|---|---|
모든 프로젝트는 필터를 걸어서 최근 작업 추이를 확인할수 있습니다. |
운영장애에대한 처리
운영장애 처리의 부작업은 하드웨어변경(장비증설)또는 설정 변경(SSL인증서) 또는 개발사항 FIX(문제되는 코드해결)이 될수있으며
개발FIX로 이어질시 핫픽스부작업생성-브랜치생성-빌드자동반영 을 통해 소스변경범위를 파악하는 과정까지 포함이됩니다.
몇년간의 장애를 파악해보면 대부분 반복적인 이슈가 많으며 원인 제공은(실수,업데이트 절차,공격,개발누락) 다양하지만
해결과정은 다양한 IT기술로 인해 처리가됩니다. 어떻게 문제를 해결했나? 과거사례를 통해 경험하지 못한것에대한 처리방법 습득도 가능하며
장애를 유발하는 잘못된 코드에 대한 파악도 가능하게됩니다. 과거에했던 실수는 반복될수 있으며, 원척적으로 장애에대한 처리능력과
장애를 막으려는 노력은 개인이아닌 이러한 운영 경험을 자료화해서 팀이 가져야할 덕목이며
다양한 사례를 통해 문제해결방법을 익히는 것은 아주 직관적이고 명료합니다.
긴급반영(HotFix) 코드가 생기면 보통 운영에 로컬에 빌드된 소스를 바로 반영해 버리는 경우가 생깁니다.
이것역시 명시적으로 티켓화 하지 않으면, 잠수함패치로 이어지며 수동반영을 허용하는것은
QA품질에대한 보증자체를 하지 않는다란 의미이며, 심각하게는 개발자에게 악성코드를 심을수 있는 기회를 주는것입니다.
착한개발자의 수동반영이 좋은케이스일때 짧은시간에 문제해결이 되지만, 나쁜개발자는 작은 문제를 해결하다가
더 큰문제를 만들어내면서 HotFix를 반복한다는점입니다.
또한 이렇게 해결된 내용은 해결과정에대한 정보가 없기때문에 장기적인 팀의 운영 능력 축적 입장에서는 아무런 도움이 안됩니다.
이것은 착하던/나쁘던 고약한 문제입니다.
고약한 문제란? 고약한(wicked)이란 용어는 크고 복잡한 기술적 특성이 있으면서 도덕적 특성도 함께 내재한
문제를 표현하고자 선택하였다. 이것에 반대되는 용오가 합당한(righteous) 해결책이다
-고약한 문제 합당한 해결 ,폭포수 모델의 한계와 애자일 인식의 뿌리책에서
작업흐름
커스텀한 작업흐름을 생성하여 , 운영장애처리와같은 커스텀한 해결 프로세스를 정의하여
관리가 가능합니다.
운영장애가 어떻게 처리가 되는지 실시간 리포팅기능
( 장애이슈가 어떻게 문서에 동적으로 언급이 될수있나? 위키의 문서는,이러한 연동부분에대해서는 동적인 문서라 할수 있습니다.)
| type | key | summary | assignee | reporter | priority | status | resolution | created | updated | due |
|---|---|---|---|---|---|---|---|---|---|---|
|
JQL and issue key arguments for this macro require at least one Jira application link to be configured |
||||||||||