Page History
Table of Contents |
---|
Info |
---|
대충 살펴보는 Atlassian Tools ( JIRA + Confluence + Bitbucket + Bamboo ) Atlassian 홍보하는 내용은아니며, OPEN진영에서도 약간의 노력으로 통합이될것으로 예측하며 PMS 시스템이 어떠한 방향으로 가야하는지 고민하기위해 설치하고 스펙 확인중에 있습니다. |
통합기능
...
JIRA : 이슈관리
Confluence : 팀협업을 위한 공간 문서관리 및 개인공간제공
Bitbucket : 소스 형상관리 및 코드리뷰및 머지기능 지원
Bamboo : 지속적 빌드/배포를 지원하는 CI툴
생성된 티켓(Task)에서 직접 개발 브랜치 생성가능
Info |
---|
지라의 선택이유는 실제 이것을 잘 활용하는 개발팀 내에서 무의식중으로 사용해서 익숙해서이며 개발 프로세스가 어떻게 개선이 되었나? 경험을 바탕으로 지라의 기능을 통해 간단하게 설명을 하는 페이지입니다. 티켓의 범위란 어떠한 단위 스토리,작업,부작업등이 될수 있고 티켓발급은 누군가가 해야할일이 생겼다란 의미도 될수있습니다. 익숙하지 않는 단어라 여기서 티켓=TASK=작업 단위로 한정짓겠습니다. |
...
...
PMS 티켓이 없으면, 개발일을 하지 못하게 하는건 아주 단순하고 강력한 프로젝트 관리방법입니다.
...
title | 티켓과 관련된 경험담 |
---|
실제로 최고 관리지침이 갑자기 내려왔습니다. 티켓없이는 그냥 놀아라~
이것은 티켓없이 개발이 진행되고, 빌드관리자의 수동반영 경고를 무시하고 운영에 반영하는
고약한 문제를 인지한 상위관리자가 내린 지침이였습니다.
처음에는 혼란이였습니다. 작은단위의 일을 명시적으로 타이틀화를 해야하는것 부터 시작해야
했으며 작명은 쉬운일이 아닙니다. 사실 이런게 귀찮아 비싼 PMS툴을 도입해도 잘 기입하려 하지 않습니다.
문의에 대한 처리도(사소한 문제라고 생각한부분) 티켓을 통해 명시화 해야했습니다.
그 이전에는 어떠한 프로젝트진행과정중 비지니스로직에해당하는 문의가 구두또는
메신져를 통해서 전달이 되면서 왜곡이 되고 그 왜곡된 사실을 타팀 운영개발에 반영이 된다란것입니다.
그러한 잘못된 정보제공자를 찾기위해 메일로그/메신져로그등을 확인하면서 책임자를 찾으려했으며
중요한 올바른 정보도 메일어딘가에 있었다는 사실입니다.
이렇게 아날로그적으로 작업을 진행하는게 올바르다라고 생각했으며
우리가 하고있는 작은 일들을 명시화함으로 그러한게 잘못된것임을 알아가기 시작했으며
다음과 같이 개선이 되었습니다.
이러한 활동이 TASK로 명시화가 되거나, 관련 티켓에 정보를 추가하면
정보제공자는 적어도 어떠한 다이어그램을 그려가면서 설명하려하고 팀내에는 공유가되기때문에
그것이 올바른지 다시 한번 확인할수 있습니다.
이것의 원초적 문제는 설계문서가 약할뿐더러 설계문서와 코드가 일치하지 않는 본질적인 문제에서
시작한 문제이나 MBD(ModelBaseDesign) MDD(Model Driven Development)를 사용해서 해결의
실마리를 찾으려는 노력으로 연결이 된다란 것입니다.
실제 실제 PMS의 티켓(TASK)가 이 만들어지면 어떠한 기능을 활용할수 있는지 살펴보겠습니다.
개발티켓에서 브랜치를 직접 생성할수있으며 생성 할수있으며 소스관리,코드리뷰,자동배포등 티켓을 통해 유기적으로 할수 있게됩니다.
어떠한 이유가 없이는(Git에서 직접) 소스 커밋도 되면 안되고, 언제 머지가될지 모르는 브랜치 생성도하면 안되기 순수연구목적을위한 개발이라할지라도
브랜치 생성하면안됩니다. 모든 활동은 팀의 소중한 자산이기때문에 추적이 되고 측정이 되어야하기 때문입니다.
분기점(브랜치) 만들기를 수행했을때 작동되는 UI
PMS에서 관리되는 티켓에의해서만 브랜치 생성이 되기때문에 누락될일이 없습니다. (물론 GIT자체의 기능을 막는것은 아니며 정책입니다. ) |
---|
해당 티켓에서 머지가가능하며 또한 코드리뷰를 통해 , 머지를 유보할수 있습니다. |
코드리뷰 코멘트에대한 대응으로, 피드백 교환및 바로 개선작업을 만들수가 있습니다. 위 모든것은 GITLAB자체에도 지원하는 기능이며, PMS TASK와 별개로 작동되어 추적이 불가한 사항을 보완하는 연동기능입니다. |
밤부를 통한 빌드및 배포 플랜
...
기본 지원 빌드툴
빌드및 배포계획수립
디플로이 방법 선택
디플로이 성공후 실행계획
운영에 배포자동화는 개발티켓에서 이루어지는것이 아니기때문에 좀더 좀더 엄격한 전략이 필요합니다.
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
Warning | |||||||||
|
티켓(Task)을 통해 문서화 추적기능
...
프로젝트 메니져(지라) 에서 문서를 언급을 하던지?
문서(위키)에서 관련 티켓을 언급하던지? 둘중하나를 하면 쌍방 연결이됩니다.
문서화과정이 개발과정과 분리된게 아닌 동시에 진행되고 포함되어야 항목입니다.
어떠한 프로젝트 진행중, 대부분 여러사람에게 유사한 질문을 받게되며 그런 질문을
예측하거나 여러번 받았을시 차라리 문서화하는게 안 귀찮습니다.
문서화는 개발과정에서 분리되어 뒤에하는게 아닌, 동시에 해야하는것입니다.
지라 티켓에서 언급된 문서
위키(문서화)에서 연결된 지라 연결
스프린트 관리
작업을 스프린트(1~3주간단위)단위로 지정하고 관리를 쉽게할수 있습니다.
스프린트는 한달이상의 계획으로 밀린 문서화와 테스트 품질향상을 마지막에 몰아서 하는 리스크를 줄이기위함입니다. (폭포수모델의 위험)
개발 배포단위를 작게 나눠 개발-문서화-배포-TEST를 지속적 진행하여 작은단위로 통합하는게 목표이며(애자일에서 주로 언급)
배포자동화툴-QA및 개발이슈를 관리하는 프로젝트관리툴 -소스관리툴-문서화툴 등이 아주 잘 연동이 되어야합니다.
...
title | 스프린트와 관련한 경험담 |
---|
실제 운영과 신규기능을 동시에 추가해야하는 개발팀에서는 업데이트 주기가 느슨한 폭포수 모델로 진행했으며
아직 운영을 하지않는 신규 개발팀에서는 스크럼방식을 도입하고 스프린트단위로 작게 기존기능을 따라오고 개선기능을 추가하려했습니다.
순발력있게 개선된 기능을 짧은주기로 배포및 QA까지 마치는것은 이상적이나, 기존 서비스가 솔리드형태로 뭉쳐져 있었고
어떠한 작은것을 고쳤을때 영향범위 측정이 안되고, 자동화테스트툴이 준비가 안되어 작은수정 몇가지에도 풀테스트가 필요했기때문에
이미 개발 프로세스가 고착화된 실제 운영서비스에서 새로운 개발 프로세스를 도입하는것은 쉽지 않습니다.
...
어떠한 주기및 버젼을 설정하여, 품질검증 배포완료까지 어떠한 구간에 완료되어야하는 내용들 관리가가능합니다.
이렇게 진행된 티켓들의 리포팅은 자유롭게 자동생성가능합니다. (별도의 리포팅기능이 있으나, 위키에서도 동적으로 언급 가능합니다.)
스프린트 없음은 스프린트에의해 관리되지 않고 처리된작업입니다. 모든 작업에대해 스프린트를 강제할 필요는 없습니다. | |
---|---|
프로젝트는 내 필터를 걸어서 최근 작업 추이를 확인할수 있습니다. |
운영장애에대한 처리
운영장애 처리의 부작업은 하드웨어변경(장비증설)또는 설정 변경(SSL인증서) 또는 개발사항 FIX(문제되는 코드해결)이 될수있으며
개발FIX로 이어질시 핫픽스부작업생성-브랜치생성-빌드자동반영 을 통해 소스변경범위를 파악하는 과정까지 포함이됩니다.
몇년간의 장애를 파악해보면 대부분 반복적인 이슈가 많으며 원인 제공은(실수,업데이트 절차,공격,개발누락) 다양하지만
해결과정은 다양한 IT기술로 인해 처리가됩니다. 어떻게 문제를 해결했나? 과거사례를 통해 경험하지 못한것에대한 처리방법 습득도 가능하며
장애를 유발하는 잘못된 코드에 대한 파악도 가능하게됩니다. 과거에했던 실수는 다른사람이 반복할수 있으며 , 원천적으로 장애에대한 처리능력과
장애를 막으려는 노력은 개인이아닌 이러한 운영 경험을 자료화해서 팀이 가져야할 덕목이며, 이러한 자료를 토대로 장애방지 룰이 생기게됩니다.
다양한 사례를 통해 문제해결방법을 익히는 것은 아주 직관적이고 명료합니다.
Info |
---|
긴급반영(HotFix) 코드가 생기면 보통 운영의 로컬에 빌드된 소스를 바로 반영해 버리는 경우가 생깁니다. 이것역시 명시적으로 티켓화 하지 않으면, 잠수함패치로 이어지며 수동반영을 허용하는것은 QA품질에대한 보증자체를 하지 않는다란 의미이며, 심각하게는 개발자에게 악성코드를 심을수 있는 기회를 주는것입니다. 착한개발자의 수동반영이 좋은케이스일때 짧은시간에 문제해결이 되지만, 나쁜개발자는 작은 문제를 해결하다가 더 큰문제를 만들어내면서 HotFix를 반복한다는점입니다. 또한 이렇게 해결된 내용은 해결과정에대한 정보가 없기때문에 장기적인 팀의 운영 능력 축적 입장에서는 아무런 도움이 안됩니다. 이것은 착하던/나쁘던 고약한 문제입니다.
|
하위 Task관리
...
어떠한 작업이 하위 Task가 모두 완료되어야 처리되는 사항이면, 하위 Task로 등록하여 그룹관계를 만들수 있습니다.
연관: 관련이 있는 작업으로 단순하게 연결
의존: 상위작업에 영향이 있는것으로 상위 의존관계연결
하위: 그룹핑이 되어 하위가 처리되어야 상위가 해결이됨
ex>티켓의 예는 운영장예처리이며 하드웨어변경/소프트웨어변경/코드변경등 다양한 TYPE 대응방법이 있습니다. 코드변경은 그 코드의 변경까지 추적이되어야 하며
해결방법은 누적되어 해결처리에대한 자산으로 그것이 코드이던지 하드웨어 설정변경이던지 간에
( 한사람이 똑같은 실수를 하는게 아닌, 똑같은 실수를 새로운 사람이 반복하기 때문입니다.)
작업흐름 설계및 리포팅
작업흐름을 직접 생성하여 , 운영장애처리와같은 커스텀한 해결 프로세스를 정의하여
...
운영장애가 어떻게 처리가 되는지 실시간 리포팅기능
( 장애이슈가 티켓이 어떻게 정적인 문서에 동적으로 어떻게 언급이 될수있나? 위키의 문서는,이러한 연동부분에대해서는 동적인 문서라 할수 있습니다JIRA티켓은,리포팅이 자유롭습니다.)
Jira | ||||||
---|---|---|---|---|---|---|
|
티켓과 관련된 대화 채널 생성
뎃글을 통한 피드백은 오랜시간이 걸리수 있으며 , 다소 긴급 사안에대한 처리를 실시간 채팅을 통해 자동이력을 남깁니다. 채팅을지원하며 자동이력을 남깁니다.
사실 중요한 즉시의사결정및 중요한 내용이 채팅을 통해 이루어지며
지라는 그것을 놓치지 않습니다.
채팅을 통한 문의처리에 대해 문제점을 살펴봅시다.
문의자1> 안녕하세요 OOO 입니다.
......... 답변없음 답변자1은 바빠서 인사에 응답을 못하고 하루가지나 답변을함
답변자1> 안녕하세요 무슨일이신가요?
.......... 문의자1이 바빠서 또 하루를 까먹음
문의자1> 넵 ....OOO일때문에...OOO를 해야하는데 어떻게해야할까요?
........... 그리고 3시간이 흘렀습니다.
답변자1> 넵 이건은 PMS Task에 등록을 하고 저에게 할당 해주십시오
문의자1> 넵 답변감사합니다. 등록하여 진행하겠습니다.
............ 그리고 또 하루가 지났습니다.
간단한 이슈를 이해시키고 Task에 등록하는데 3일이 걸렸고 핑퐁하며 최종 처리되기까지 1주일이 실제 소요되었습니다.
자 이것을 개선해보겠습니다.
애시당초 담당자는 누구인지 모르겠지만... 우선 처리해야할 Task를 명확하게 정리합니다.
문의자1이 Task를 만들었습니다. 그리고 누가 해결해야할지 모르기때문에 채팅을 통한문의를 합니다.
채팅> #1234 OOOO 이슈로 문의1님이 채팅신청을 하였습니다.
문의자1> 안녕하세요 1234이슈로 문의를 드립니다.
......... 답변자1은 바빠서 다음날 답변을 합니다.
답변자1> Task확인하였고 처리하도록하겠습니다.
2일만에 사소한 Task를 해결하였습니다.
물론 위 사례는 사내채팅이 PMS와 자동연동되어야 함을 의미 하지 않습니다.
업무채팅시 인사를 주고받는데 쓸데없는 시간을 낭비하지말자는 의미입니다.
조직이 클수록 어떠한 Task를 정확하게 처리해야할 대상을 찾는것은 어려울수 있으며
처음부터 상대가 이해할수있는 구체적인 Task를 작성하고 문의를 하자는 내용입니다.