[아이디어] 개발 - 배포 주기 변경에 대한 제안

[longfin]

이 예시 나 action update 등의 hard fork 상황에 발생하는 체인 정합성 이슈를 방지하기 위해서 다음과 같이 개발-배포 process 를 변경하면 어떨지 생각해보았습니다.

이 아이디어는 현재 게임 개발-배포 일정을 매우 크게 변경시키게 됩니다

핵심 아이디어

• 코드가 배포되는 시점과 hard fork 가 일어나는 시점을 분리합니다.

핵심 변경사항

1. 코드는 실제 적용 예정 시점보다 한 버전 더 빨리 배포됩니다. 예를 들어 N+2 버전에 적용될 코드는 N+1 버전이 적용(Hard Fork) 되기 전에 이미 코드로 배포되어 있습니다.
2. 배포된 코드가 적용되는 시점(Hard Fork 시점)은 배포 시 target block 을 미리 정하고, 이 시점부터 protocol 이 자동으로 새 버전을 따릅니다.

---

편의를 위해 버전은 100부터 100 단위로, block 은 1M(1,000,000) 부터 1M 단위로 배포됨을 가정합니다.
아래 그림은 버전별 코드 배포와 hard fork 시점을 간략히 도식화한 것으로, 표와 같이 동일한 시점에 여러 이벤트가 일어날 필요는 없습니다.

현행 개발-배포 과정

• 새 버전이 배포되면 이 시점부터 Hark Fork 가 되고, 하위호환을 위해 일정 기간의 유예를 두고 이전 버전을 obsolete 합니다.

blk \ ver	100	200	300	400
1M	현재 버전	개발 완료	개발중
2M		배포 == Hard Fork Obsolete 100	개발 완료	개발중
3M			배포 == Hard Fork Obsolete 200	개발 완료
4M				배포 == Hard Fork Obsolete 300

제안하는 개발-배포 과정

• 새 버전이 배포되어도 바로 Hard Fork 가 일어나지 않고 미리 정해둔 일정에 따라 Hard Fork 가 일어나면서 자연스레 이전 버전을 obsolete 합니다.

blk \ ver	100	200	300	400
1M	현재 버전	배포 완료 Fork target = 2M	개발 완료	개발중
2M		Hard Fork == Obsolete 100	배포 완료 Fork target = 3M	개발 완료
3M			Hard Fork == Obsolete 200	배포 완료 Fork target = 4M
4M				Hark Fork == Obsolete 300

---

기대하는 효과

1. 코드가 개발, 배포되는 시점과 효과가 발생하는 시점에 시간 간격이 있기 때문에 현재와 같이 일정 기간 이전 버전의 action 을 받아주는 유예기간을 둘 필요가 없습니다. 항상 최신 1개의 action 만 유효한 상태를 유지할 수 있습니다.
2. 코드가 개발, 배포되는 시점과 효과가 발생하는 시점에 시간 간격이 있기 때문에 test 와 bugfix 를 할 수 있는 여유가 있습니다.
3. 코드가 미리 공개되기 때문에 mod, tool 등을 만드는 외부 개발자가 새 버전에 대한 업데이트를 미리 할 수 있습니다.

정책

아래 정책은 실제 적용을 위해 수정해야 할 수 있습니다.

1. 개발 일정을 정하고, 이에 따라 각 버전이 실제로 효과를 발휘할 block height 를 미리 정한다.
2. N+2 버전의 소스코드는 N+1 버전이 hard fork 되기 전까지 배포를 완료한다. N+2 버전에 대한 release note 는 N+2 버전의 코드가 배포되는 시점에 미리 공지한다.
3. N+2 버전의 hard fork 가 일어나기 전에 bugfix 가 필요한 경우 N+1 버전에 bugfix version 을 올린다. 이미 배포된 코드에 대한 bugfix 이기 때문에 N+2 버전을 덮어쓰지 않는다(잠수함 패치 방지).
4. hark fork 가 일어난 버전에 대한 bugfix 가 필요한 경우 즉시 반영하지 않고 위의 원칙과 동일하게 hard fork target block height 를 지정한다. 이때 block height 는 bugfix 의 경중에 따라 다르게 할 수 있으나 최소 30분정도의 텀¹ 을 둔다.

Footnotes

1. 적절한 시간이 어느정도인지는 별도의 논의를 통해 결정하는 것이 필요합니다 ↩

[longfin]

@jaeho0103 22년 4분기에 얘정 되어 있는 개발 일정상, 해당 제안을 다 맞추어서 개발하는 것은 곤란한 것으로 알고 있습니다. 현황 분석이나 검토를 위해, 현재 잡혀 있는 개발 일정(주요 마일스톤)을 코멘트로 남겨주실 수 있을까요? (일부만이라도 떼어서 적용할 수 있을지 검토를 위함입니다. 🙏 )

[jaeho0103]

	아레나	월드보스	겨울 이벤트	RC
10월 1주	시즌 7(10.4)	시즌1(10.3). 오프
10월 2주	시즌 7	오프
10월 3주	시즌 7(10.17), 오프	오프		100310 (10.20)
게임 개선 및 챔피언 1 칭호
10월 4주	오프, 시즌 8(10.25)	오프
11월 1주	시즌 8	오프
11월 2주	시즌 8(11.8), 오프	오프, 시즌 1-2(11.10)		100320 (11.9)
월드보스 & 아레나 개선
11월 3주	오프, 챔피언쉽2(11.15)	시즌1-2(11.17)오프
11월 4주	챔피언쉽 2	오프,
11월 5주	챔피언쉽 2(11.29), 오프	오프,시즌 1-3(11.29)		100330(11.30) - 그랜드 피날레
12월 1주	오프, 그랜드피날레(12.6)	시즌 1-3(12.5)오프
12월 2주	그랜드피날레(12.13),오프	오프		100340(12.14) 룬
일정 변경 어려움
12월 3주	오프	오프	오픈(12.20)	100350 (12.20)
겨울 이벤트
12월 4주	오프,시즌 9(12.27)	오프,시즌 1-4(12.27)	진행
1월 1주	시즌 9	시즌 1-4(1.3), 오프	진행
1월 2주	시즌 9(1.10), 오프		클로즈(1.10)	100360

위의 내용은 https://www.notion.so/planetarium/22-4Q-9C-e4e2c981dc5d4f369a3fa1ddf10f22ee 에서 확인 가능하십니다.

[ipdae]

• 미리 배포를 해두고 실행을 사전에 막는건 현재 방식을 뒤집어서 Execute안에서 해당 높이가 되기전에 막으면 되니 큰 어려움은 없지 싶습니다.
• 다만 걱정이 되는건 현재 액션 버저링 방식때문에 미리 배포된 상태에서 자연스럽게 액션이 스위칭되는 부분입니다.

class	action_type
HackAndSlash	hack_and_slash18
HackAndSlash17	hack_and_slash17
HackAndSlash0	hack_and_slash

체인, 네트워크상에선 action_type이 identifier가 되어 버전에 맞춰 직렬화 / 역직렬화가 따라가는 방식이지만, Headless, DataProvider, NineChronicles 등 lib9c를 사용하는 서비스들이 전부 숫자가 붙지않은 클래스를 최신 버전으로 사용한다는 가정하에 동작하고 있는데, 이 부분의 호환을 어떻게 맞출것인지에 대한 전략이 필요해 보입니다.