Page History
생성된 티켓(Task)을 통해서만 개발(브랜치생성) 가능
...
PMS 티켓이 없으면, 개발일을 하지 못하게 하는건 아주 단순하고 강력한 프로젝트 관리방법입니다.
...
분기점(브랜치) 만들기를 수행했을때 작동되는 UI
Git에서 직접 브랜치를 생성하고 작업을 시작하면 해당 작업이 프로젝트 관리에서 제외될수가 있습니다.
...
Info |
---|
운영배포 티켓은 운영에 반영되는 만큼 엄격한 다음과같은 엄격한 조건을 걸수가 있습니다.
|
티켓을 통해 문서화 추적기능
...
프로젝트 메니져(지라) 에서 문서를 언급을 하던지?
문서(위키)에서 관련 티켓을 언급하던지? 둘중하나를 하면 쌍방 연결이됩니다.
지라에서 티켓에서 언급된 문서
위키(문서화)에서 연결된 지라 연결
스프린트 관리
...
작업을 스프린트(1~3주간단위)단위로 지정하고 관리를 쉽게할수 있습니다.
...
스프린트 없음은 스프린트에의해 관리되지 않고 처리된작업입니다. | |
---|---|
모든 프로젝트는 필터를 걸어서 최근 작업 추이를 확인할수 있습니다. |
운영장애에대한 처리
...
운영장애 처리의 부작업은 하드웨어변경(장비증설)또는 설정 변경(SSL인증서) 또는 개발사항 FIX(문제되는 코드해결)이 될수있으며
...
Info |
---|
긴급반영(HotFix) 코드가 생기면 보통 운영에 로컬에 빌드된 소스를 바로 반영해 버리는 경우가 생깁니다. 이것역시 명시적으로 티켓화 하지 않으면, 잠수함패치로 이어지며 배포자동반영없이 수동반영을 허용하는것은 QA품질에대한 보증자체를 하지 않는다란 의미입니다. 이렇게 패치가 진행되는 경우 가장 좋은케이스일때 짧은시간에 문제해결이 되지만, 가장 나쁜 케이스는 작은 문제를 해결하다가 더 큰문제를 만들어내면서 HotFix가 반복된다는 것입니다. 또한 이렇게 해결된 내용은 해결과정에대한 정보가 없기때문에 장기적인 팀의 운영 능력 축적 입장에서는 아무런 도움이 안됩니다. |
작업흐름
커스텀한 작업흐름을 생성하여 , 운영장애처리와같은 커스텀한 해결 프로세스를 정의하여
...