왜 우리는 UI를 버전 관리하지 않는가?

우리는 2015년부터 UI를 버전 관리해 왔습니다. 몇 달 동안 탭을 열어둔 사람들로 인해 발생한 이상한 버그 보고를 처리한 후에 시작했습니다. 백엔드 계획과 이전 버전과의 호환성을 위한 데이터 처리가 필요하지만, 해결 가능한 기술적 문제입니다. 프론트엔드의 API 호출은 활성 버전을 함께 보내 백엔드가 이전 버전의 호출을 이해하고 봉투와 페이로드의 버전 업그레이드를 수행할 수 있게 하며, 프론트엔드는 추가 필드를 무시하도록 설계해야 합니다. 이 모든 것은 테스트 가능하며, 일단 갖춰지면 이상한 불일치 버그로부터 보호하고, 병렬로 A/B 실험을 할 수 있으며, 이상한 문제를 해결하기 위한 상세한 모니터링을 제공합니다. 활성 버전 목록을 보고 백엔드에 실제로 연결되는 것들의 긴 꼬리를 보는 것은 꽤 정신이 번쩍 들게 합니다.

일부 오래된 소프트웨어/SaaS UI에서 버전 번호가 표시되는 것을 본 적이 있습니다. 그러나 사용자가 전환할 수 있게 하는 것은 일반적으로 변경이 백엔드와 프론트엔드 모두에서 발생하기 때문에 의미가 없을 수 있으며, 공급업체는 전환에 필요한 복잡성 때문에 버전 전환을 제공하고 싶어하지 않습니다.

큰 변화가 있을 때, 많은 사이트와 일부 애플리케이션에서 사용자가 새 버전을 시험해 보거나, 필요에 맞지 않거나 마감일이 있어 이전 워크플로우를 사용해야 할 때 이전 버전으로 돌아갈 수 있게 하는 것을 보았습니다. Reddit과 Outlook이 가장 먼저 떠오르는 예이지만, 더 많이 보았습니다. 심지어 전력 회사도 그렇게 했습니다. 그러나 이것은 큰 변화에만 해당하며, 보통 단순히 old|new 토글일 뿐, 사용자가 역사의 어떤 지점으로든 돌아갈 수 있는 완전한 버전 관리는 아닙니다. 유지 관리의 악몽이 될 것 같고, API와 달리 UI에 의존하는 코드는 거의 없기 때문입니다... 적어도 그렇기를 바랍니다.

저에게는 업그레이드 러닝머신을 피하는 것이 안정적인 인터페이스(및 워크플로우)를 유지하는 신뢰할 수 있는 방법입니다. 물론 그 점심은 공짜가 아닙니다. 행운을 빕니다.

원한다면 할 수 있습니다. 특히 버전이 있는 API를 사용하는 경우 선택입니다. 모바일 클라이언트를 버전 관리하는 것과 같습니다.