Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

형상관리 입장에서는 Master코드의 커밋을 개발자가 하면 안됩니다. 핫픽스라할지라도 핫픽스라할지라도  생성된 티켓의 브랜치를 생성통해 작업이 진행되어야하며진행되어야 하며 사소한 개선 변경역시 포함됩니다.

PMS에서 브랜치를 생성하게되며 부가적으로 GIT에서 직접 브랜치생성을 막지는 않지만,  PMS에서 브랜치를 생성하게되며 전체 프로젝트 스케쥴및 배포관리등을 유기적으로 할수 있게됩니다.

...

장애를 막으려는 노력은 개인이아닌 이러한 운영 경험을 자료화해서  팀이 가져야할 덕목으로 생각이됩니다. 

Info

긴급반영(HotFix) 코드가 생기면 보통 운영에 로컬에 빌드된 소스를 바로 반영해 버리는 경우가 생깁니다.

이것역시 명시적으로 티켓화 하지 않으면, 잠수함패치로 이어지며 배포자동반영없이 수동반영을 허용하는것은  

QA품질에대한 보증자체를 하지 않는다란 의미입니다.

이렇게 패치가 진행되는 경우 가장 좋은케이스일때 짧은시간에 문제해결이 되지만, 가장 나쁜 케이스는 작은 문제를 해결하다가

더 큰문제를 만들어내면서 HotFix가 반복된다는 것입니다. 또한 이렇게 해결된 내용은 해결과정에대한 정보가 없기때문에

장기적인 팀의 운영 능력 축적 입장에서는 아무런 도움이 안됩니다.



작업흐름

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

...