You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 92 Next »



대충 살펴보는 Atlassian Tools ( JIRA + Confluence + Bitbucket + Bamboo )

Atlassian 홍보하는 내용은아니며, OPEN진영에서도 약간의 노력으로 통합이될것으로 예측하며

PMS 시스템이 어떠한 방향으로 가야하는지 고민하기위해 설치하고 기능확인중에 있습니다.


통합기능

JIRA : 이슈관리

Confluence : 팀협업을 위한 공간 문서관리 및 개인공간제공

Bitbucket : 소스 형상관리 및 코드리뷰및 머지기능 지원

Bamboo : 지속적 빌드/배포를 지원하는 CI툴


생성된 티켓(Task)에서 직접 개발 브랜치 생성가능

PMS 티켓이 없으면, 개발일을 하지 못하게 하는건 아주 단순하고 강력한 프로젝트 관리방법입니다.


 실제 PMS의 티켓(TASK)이 만들어지면 어떠한 기능을 활용할수 있는지 살펴보겠습니다.

개발티켓에서 브랜치를 직접 생성 할수있으며   소스관리,코드리뷰,자동배포등 티켓을 통해 유기적으로 할수 있게됩니다.

어떠한 이유가 없이는(Git에서 직접) 소스 커밋도 되면 안되고, 순수연구목적을위한 개발이라할지라도

브랜치 생성하면안됩니다.  모든 활동은 팀의 소중한 자산이기때문에 추적이 되고 측정이 되어야하기 때문입니다.


분기점(브랜치) 만들기를 수행했을때 작동되는 UI  


PMS에서 관리되는 티켓에의해서만 브랜치 생성이 되기때문에

누락될일이 없습니다. (물론 GIT자체의 기능을 막는것 아닙니다. )

해당 티켓에서 머지가가능하며 또한 코드리뷰를 통해 , 머지를 유보할수 있습니다.

코드리뷰 코멘트에대한 대응으로, 피드백 교환및 바로 개선작업을 만들수가 있습니다.

위 모든것은 GITLAB자체에도 지원하는 기능이며, PMS TASK와 별개로 작동되어

추적이 불가한 사항을 보완하는 연동기능입니다.





밤부를 통한 빌드및 배포 플랜

기본 지원 빌드툴

빌드및 배포계획수립


운영에 배포자동화는 개발티켓에서 이루어지는것이 아니기때문에 좀더 좀더 엄격한 전략이 필요합니다.  

운영배포 티켓은 운영에 반영되는 만큼 다음과 같은 엄격한 조건을 걸수가 있습니다.

  • QASignOFF가 나지 않는 운영배포는 실행되면 안됨
  • 처리하지 못한 몇가지 이슈가 남아 있을시, 연기가되거나 최고책임자의 조건부 승인이 필요함 -처리하지 못한 이슈를 은닉하고 서비스에 반영될시 그책임은 개발자가 지기때문입니다.
  • 배포순서에의해 문제가 생길수 있기때문에 배포절차를 명시적으로 언급해야하고 롤백 계획도 수립해야함 -롤백은 사실 엄청난 결정력이 따릅니다.
  • 환경설정변경 의존 라이브러리 수동설정등이 있을시 언급이되어야하고 빌드책임자의 승인거부항목으로 자동화에대한 고민이필요함
  • 도메인에따른 SSL설정의 중앙화(IIS에서 SSL을 위한 443Port Listen을 하지 않음), DB암호 설정의 중앙화(개발자는 운영 DB의 암호를 알면안됨),어플리케이션 설정 빌드툴에 분리화(Ex>각종 IP설정및,튜닝요소)
  • 소스에서 환경설정을 분리함으로 개발자에의한 수동설정에 대한 이슈가 점점 없어지기 시작했습니다.
  • 소스 빌드 자동외에 외부 라이브러리 관리를 넥서스라는 중앙 자료실에서 관리하여 빌드툴과 연동됨(서비스코드에서 외부 라이브러리 코드를 분리하고 ,어느 특정 라이브러리의 특정버젼이 인터넷상에서 제거되었을시 , 잘못된 인터넷경로를 참조하여 빌드되었을시등 빌드가 깨지는 문제를 막기 위함입니다.)

자동반영이 준비안되고수동반영으로 운영에 반영을 했을시점, 빌드관리자는 항상 해당 반영의 승인을 거부하였습니다.

하지만, 약속된 날자에 프로덕트(운영) 반영이 필요했기에 프로덕트 관리자의 조건부 추가 승인이 필요했으며

프로덕트가 관리자가 빌드관리자보다 권한이 높다는 의미는 아니며 , 배포수동은 자동화가 이루어질때까지 할수밖에없으며

각 책임자를 두어 현재의 빌드 배포는 위험성이 존재함을 항상 각인하였기에 사소한 프로젝트도 모두 자동반영이 되었습니다.


티켓(Task)을 통해 문서화 추적기능


프로젝트 메니져(지라) 에서 문서를 언급을 하던지?

문서(위키)에서 관련 티켓을 언급하던지?  둘중하나를 하면 쌍방 연결이됩니다.

문서화는 개발과정에서 분리되어 뒤에하는게 아닌, 동시에 해야하는것입니다.

지라 티켓에서 언급된 문서

위키(문서화)에서 연결된 지라 연결


스프린트 관리

어떠한 주기및 버젼을 설정하여, 품질검증 배포완료까지 어떠한 구간에 완료되어야하는 내용들 관리가가능합니다.



이렇게 진행된 티켓들의 리포팅은 자유롭게 자동생성가능합니다. (별도의 리포팅기능이 있으나, 위키에서도 동적으로 언급 가능합니다.)

스프린트 없음은 스프린트에의해 관리되지 않고 처리된작업입니다.


프로젝트는 내 필터를 걸어서 최근 작업 추이를 확인할수 있습니다.



하위 Task관리


어떠한 작업이 하위 Task가 모두 완료되어야 처리되는 사항이면, 하위 Task로 등록하여 그룹관계를 만들수 있습니다.

연관: 관련이 있는 작업으로 단순하게 연결

의존: 상위작업에 영향이 있는것으로 상위 의존관계연결

하위: 그룹핑이 되어 하위가 처리되어야 상위가 해결이됨

ex>티켓의 예는 운영장예처리이며 하드웨어변경/소프트웨어변경/코드변경등 다양한 TYPE 대응방법이 있습니다. 코드변경은 그 코드의 변경까지 추적이되어야합니다.

작업흐름 설계및 리포팅

작업흐름을 직접 생성하여 , 운영장애처리와같은 커스텀한 해결 프로세스를 정의하여

관리가 가능합니다.

운영장애가 어떻게 처리가 되는지 실시간 리포팅기능

( 티켓이 어떻게 정적인 문서에 동적으로 어떻게 언급이 될수있나? JIRA티켓은,리포팅이 자유롭습니다.)  

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

티켓과 관련된 대화 채널 생성

다소 긴급 사안에대한 처리를 채팅을지원하며  자동이력을 남깁니다. 




  • No labels