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