WordPress 플러그인 및 테마 개발자를 위한 단계적 출시: "Clusterbug 릴리스" 방지
게시 됨: 2020-12-23마지막으로 WordPress 플러그인 또는 테마의 새 버전을 출시하여 테스트 시퀀스 균열을 통과하는 새로운 주요 버그를 실수로 추가했음을 빠르게 발견했던 때를 기억하십니까?
Yoast SEO 3.0은 2015년에 많은 웹사이트를 망가뜨렸습니다. Elementor 3.0은 올해도 마찬가지였습니다. 그리고 이것들은 100명 이상의 직원과 전담 QA 직원이 있는 우리 공간의 환상적인 회사 머리 꼭대기에 있는 두 가지 예일 뿐입니다(아니요, 버전 3.0과 관련이 없지만 소프트웨어에서 해당 버전을 건너뛰라는 신호일 수도 있습니다. )).
독학 코더이든 소프트웨어 엔지니어이든, 인디 개발자이든, 대규모 플러그인/테마 샵의 일부이든 우리 모두는 버그를 처리해야 합니다. 소프트웨어 개발에서 피할 수 없는 부분입니다.
아무리 멋진 CI/CD/테스트 자동화를 배치하더라도 모든 것을 테스트할 수는 없습니다. 서버 구성(PHP, MySql, 캐싱, 웹 서버), WP 버전, 플러그인 및 테마 조합의 수는 모두 끝이 없습니다.
그리고 그것은 반직관적입니다. 제품의 인기와 안정성이 높을수록 두려운 "Clusterbug" 릴리스의 가능성이 높아져 지원이 고갈되고 고객의 신뢰와 충성도에 큰 영향을 미치며 잠재적으로 전반적인 브랜드 평판에 해를 끼칠 수 있습니다.
버그를 피할 수는 없지만 가능한 한 위험을 완화할 수 있고 가장 확실하게 해야 합니다.
스마트폰이 있다면 친구 중 일부가 Android/iOS 업데이트를 받기 며칠, 몇 주, 때로는 몇 달 전에 받는 것을 보았을 것입니다. 그것은 우연이 아니며, 아니요, 당신에게 개인적으로 불리한 것이 아닙니다. Apple과 같은 회사가 주요 소프트웨어 업데이트를 10억 개 이상의 장치에 제공하는 데 도움이 되는 단계적 출시라고 하는 의도적인 점진적 배포 프로세스입니다.
네, 10억!
Apple의 버전 책임자가 동시에 15억 개의 모바일 장치에 대한 라이브 업데이트를 푸시해야 하는 경우 그 책임이 얼마나 되는지 이해할 수 있습니까? 할 수 없어. 나는 제정신이 있는 사람이라면 그런 책임을 지는 데 동의하지 않을 것이라고 장담합니다.
그렇다면 단계적 출시 메커니즘은 어떻게 작동합니까? 어떻게 구현할 수 있습니까? 그리고 WordPress.org는 무엇을 기다리고 있습니까? 이것들은 제가 아래에서 다룰 주제입니다.
WordPress 플러그인 및 테마의 단계적 출시란 무엇입니까?
단계적 출시를 사용하면 새 버전을 출시할 웹 사이트의 수(또는 백분율)를 지정할 수 있습니다. 단계적 출시 메커니즘을 사용하면 제한된 노출로 릴리스 주기를 시작한 다음 지원 및 피드백을 모니터링하는 동안 점진적으로 늘릴 수 있으므로 귀하와 사용자를 위한 릴리스에 대한 신뢰를 구축할 수 있습니다.
단계적 출시의 이점은 무엇입니까?
잠재적인 버그, 타사 플러그인/테마와의 충돌 또는 UI/UX 문제의 릴리스로 전체 설치 기반을 위험에 빠뜨리는 대신 점진적으로 버전을 릴리스하여 예기치 않은 문제에 노출될 사람과 웹사이트의 수를 최소화할 수 있습니다. 롤아웃 프로세스 중에 발견된 모든 문제와 버그를 제거하면 대다수의 사용자가 "성숙한" 버전과 훨씬 더 안정적인 버전에 노출될 것입니다.
우리는 새로운 릴리스의 품질을 보장하기 위해 롤링 업데이트를 사용합니다. 새 릴리스에 문제가 있는 경우 신속하게 식별할 수 있으며 소수의 사용자만 영향을 받았을 것입니다.
SeedProd 설립자 John Turner
단계적 출시를 사용하는 것은 책임감 있는 소프트웨어 출시를 위한 모범 사례입니다. 이는 WP 거품 외부에 있는 많은 회사(규모에 관계 없이)가 따르는 프로세스입니다.
WordPress 커뮤니티가 단계적 출시를 활용할 수 있는 큰 기회가 있습니다. 이에 대해서는 잠시 후에 다루겠습니다.
베타 프로그램은 단계적 출시와 유사합니까?
WordPress 제품에 대한 베타 프로그램을 설정하는 것은 좋은 시작이지만 단계적 출시만큼 효과적이지는 않으며 근본적으로 다른 목적 및 동적 기능을 가지고 있습니다.
플러그인이나 테마가 매우 인기 있고 대규모 커뮤니티가 없는 한, 소수의 사용자만이 가입에 관심을 가질 것이기 때문에 통계적으로 충분한 베타 그룹을 모집하는 것은 상당히 어렵습니다. 괜찮은 베타 테스터 그룹을 모집하는 데 탁월하더라도 제품을 테스트하기 위해 그들의 가용성과 선의에 의존해야 하며 그들이 발견한 문제를 보고하기 위해 추가 노력을 하기를 바랍니다.
얼마나 많은 사람들이 이 전체 과정을 볼 것이라고 생각합니까? 많지 않습니다.
베타 테스트는 지원 노력이 완전히 통제되고 테스터가 베타 릴리스에 문제가 있을 것으로 예상하는 사전 프로덕션 프로세스입니다. 따라서 품질에 대한 테스터의 기대는 사용자 기반의 일반적인 감정을 나타내지 않습니다.
또한 책임 있는 베타 프로그램은 테스터에게 프로덕션 환경에서 베타 버전을 사용하지 않도록 경고하므로 베타 테스트는 실제 프로덕션 웹사이트를 실제로 시뮬레이션하지 않습니다.
WordPress 플러그인 또는 테마에 대한 단계적 출시 릴리스를 관리하는 방법은 무엇입니까?
단계별 롤아웃에 대한 연구의 일환으로 저는 Amir Helzer를 만나 2년 이상의 경험을 바탕으로 WPML 및 Toolset(1,000,000개 이상의 WordPress 웹사이트에서 실행되는 플러그인)과 함께 단계별 롤아웃을 사용한 경험을 통해 배울 수 있었습니다.
다음은 Amir가 단계별 출시 구현에 대해 공유한 내용입니다.
웹사이트에서 플러그인을 설치할 때 1에서 100 사이의 임의의 숫자를 뽑아 사이트의 데이터베이스에 저장하여 기억합니다. 이 방법은 본질적으로 웹사이트를 무작위 방식으로 100개의 빈으로 나눕니다.
릴리스가 출시될 준비가 되면 선택한 단일 저장소에서만 점진적으로 사용할 수 있게 됩니다. 매일 우리는 지정된 저장소에 있는 웹사이트의 추가 5%에 대한 릴리스의 노출을 늘립니다. 그리고 진행 중인 문제를 수정하고 패치합니다.
업데이트된 버전을 사용하여 환경을 다양화하고 동일한 초기 릴리스 "피해자"를 반복적으로 피하기 위해 Amir는 모든 새 릴리스가 먼저 다른 사용자 그룹으로 이동함을 확인했습니다.
이 접근 방식은 또한 모든 사용자가 평균 릴리스 주기를 사용할 수 있게 되기까지 약 한 달이 걸린다는 것을 의미합니다.
사람들이 WP Admin에서 사용 가능한 새 릴리스를 보고 버전을 업데이트할 때까지 시간이 걸립니다. 그리고 그렇게 한 후에도 문제를 발견하는 데 며칠이 걸릴 수 있습니다.
우리의 청중 규모로 인해 필연적으로 모든 릴리스에는 몇 가지 문제가 있습니다. 우리의 주요 목표는 새로운 문제가 발생하지 않도록 하는 것이며, 발생하는 경우 문제를 해결할 수 있는 신뢰할 수 있는 프로세스를 갖추는 것입니다.
출시 주기는 정말 길지만 최악의 시나리오에서 테스트에서 놓친 미친 버그가 있더라도 사용자의 95%는 출시에 노출되지 않기 때문에 모든 드라마를 인식하지 못합니다. 안정될 때까지.
Amir는 또한 출시 전에 전체 팀과 동기화하는 것, 특히 고객 지원 및 개발의 중요성을 강조했습니다. 이러한 방식으로 팀 구성원은 유효한 문제를 확인, 확인 및 수정하고 가능한 한 빨리 패치를 릴리스하는 것을 목표로 진행 중인 릴리스와 관련된 문제로 인해 트리거된 티켓에 더 집중할 수 있습니다.
우리 팀에는 세 가지 지원 계층이 있습니다. Tier 1은 문제를 검토하고 재현하여 실제로 플러그인 릴리스와 관련된 문제인지 확인합니다. 사례가 새 릴리스와 관련된 것으로 보이면 계층 2로 이동하여 문제를 디버깅하여 릴리스와 실제로 관련이 있는지 확인하고 문제를 트리거하는 코드에서 관련 부분을 찾습니다. 유효성이 확인되면 해당 코드를 담당하는 개발자는 수정 우선 순위를 지정하기 위해 즉시 알림을 받습니다.
OnTheGoSystems는 직원이 거의 100명에 달하는 대기업이므로 단계별 출시 프로세스를 완성한 것이 합리적입니다. 그러나 하나의 지원 계층(귀하와 자신)이 있는 단일 제품 개발자인 경우에도 Amir의 통찰력은 릴리스에 전용 리소스를 할당하는 것이 중요하다는 것을 알려줄 수 있습니다. 최신 릴리스와 관련하여 "냄새가 나는" 지원 티켓의 우선 순위를 지정하고 새로운 문제에 대한 노출을 최대한 줄이는 것이 좋습니다.
단계적 출시를 지원하는 플러그인이나 테마가 거의 없는 이유는 무엇입니까?
이 기사를 작성하기 위해 준비하면서 커뮤니티에 누가 단계적 출시를 사용하고 있는지 확인하여 경험, 배운 내용 등에 대한 피드백을 얻으려고 했습니다.
당연히 내 네트워크에서 릴리스 주기의 일부로 단계적 출시를 설정한 두 개의 WordPress 회사만 찾았습니다. 많은 개발자는 개념조차 몰랐고 나머지는 배포 솔루션에서 지원하지 않기 때문에 사용하지 않습니다(또는 개발에 대해 생각했지만 시간이 없을 수 있음).
Freemius를 통해 판매하지 않는 대부분의 플러그인 및 테마 개발자는 단계적 출시를 지원하지 않는 EDD 또는 WooCommerce를 통해 웹사이트에서 판매합니다. CodeCanyon 및 ThemeForest와 같은 마켓플레이스를 통해 판매하는 사람들도 즉시 사용 가능한 솔루션을 갖고 있지 않으며 앞으로도 없을 것입니다.
개념을 알고 있는 개발자라도 단계적 출시를 지원하는 자체 메커니즘을 개발할 수 밖에 없습니다. 이러한 인프라 개발은 일반적으로 제품 회사 내에서 우선순위를 지정하기가 매우 어렵습니다.
구독하고 무료 사본을 받으십시오.
WordPress 플러그인 비즈니스 북
구독 경제에서 번영하는 WordPress 플러그인 비즈니스를 만드는 방법.
친구와 공유
친구의 이메일 주소를 입력하세요. 스카우트님, 이 책만 이메일로 보내드리겠습니다.
공유해 주셔서 감사합니다.
굉장 - 'WordPress Plugin Business Book' 사본이 방금 발송되었습니다. . 우리가 더 널리 알리도록 돕고 싶습니까? 계속해서 친구 및 동료와 책을 공유하십시오.
구독해주셔서 감사합니다!
- 귀하의 'WordPress Plugin Business Book' 사본을 다음 주소로 보냈습니다. .
이메일에 오타가 있습니까? 이메일 주소를 수정하고 다시 보내려면 여기를 클릭하세요.
단계적 출시는 어떻게 상업적 이점을 제공합니까?
현재 단계적 출시를 활용하는 사람은 거의 없기 때문에 단계적 출시를 활용하기 시작하고 웹사이트에서 적절하게 마케팅하여 방문자에게 책임 있는 출시 주기가 있음을 알리면 확실히 경쟁 우위를 확보하고 제품에 대한 신뢰를 높일 수 있습니다. /상표!
개발자의 관점에서 시장을 분석하면 많은 개발자가 경쟁업체를 밀접하게 따르고 일반적으로 수직 시장의 가격 범위 내에서 가격을 설정한다는 것을 알 수 있습니다. 이는 동일한 가격대에서 유사한 기능을 제공하는 경쟁 WordPress 제품으로 이어집니다.
구매자의 관점에서 볼 때 모든 제품이 비슷한 기능과 가격을 가지고 있기 때문에 어떤 제품을 살지 결정하는 경우가 많습니다. 그러나 비용이 동일하고 동일한 기능을 제공하거나 제공하는 여러 플러그인을 평가할 때 프로덕션 릴리스가 경쟁사보다 더 안정적이어야 함을 알고 단계적 출시를 제공하는 제품을 사용하고 싶지 않습니까?
단계적 출시는 제품과 비즈니스에 대한 자신감을 높여줍니다. 단계적 출시가 표준 관행이 되기 전에 활용할 수 있는 이점입니다(정말 그렇게 되기를 바랍니다).
Freemius, 이제 유료 플러그인 및 테마에 대한 단계적 출시 지원
프리미엄 WordPress 플러그인 및 테마 생태계에서 단계적 출시를 개척하게 된 것을 기쁘게 생각합니다. 우리의 판매 파트너는 이제 사용자 또는 지원/개발 리소스에 대한 타격을 최소화하면서 안전하고 자신 있고 안정적으로 업데이트를 릴리스할 수 있습니다.
특히 "Clusterbug" 릴리스 이후에는 브랜드에 부정적인 영향을 미칠 수 있는 잠재적 위험이 항상 존재하기 때문에 주요 릴리스가 얼마나 어렵고 신경이 많이 쓰이는지 알고 있습니다.
단계적 출시를 사용하면 파트너의 브랜드 지속 가능성 및 방어 가능성에 대한 안전망이 생기고 대규모 사용자 기반에 대한 릴리스와 관련된 불필요한 스트레스를 완화할 수 있습니다.
이는 파트너 고객을 위한 혜택으로 함께 제공됩니다. 사용자가 Freemius를 통해 판매되는 제품을 구매할 때 이제 단계적 출시로 구동되는 솔루션을 선택하고 있다는 확신을 가질 수 있으며 메커니즘을 활용하는 프리미엄 플러그인 및 테마에서 훨씬 더 안정적인 릴리스를 기대할 수 있습니다.
Freemius로 판매하는 경우 단계별 출시 메커니즘을 올바르게 사용하는 방법은 다음과 같습니다.
Freemius는 단계적 출시를 어떻게 구현했습니까?
프리미엄 플러그인 또는 테마의 잠금을 해제하기 위해 라이선스를 활성화하는 모든 웹사이트는 데이터베이스에 기록을 얻습니다. 가장 먼저 한 일은 웹사이트에서 사용할 수 있게 된 최신 제품 버전을 저장하기 위해 새로운 last_served_update_version 속성을 도입하는 것입니다.
그런 다음 두 가지 새로운 속성인 limit , uniques 를 사용하여 릴리스 데이터를 저장하는 테이블을 강화했습니다.
개발자가 버전을 출시된 것으로 표시하면 다음 대화 상자가 표시되어 유료 버전을 출시하려는 활성 라이선스가 있는 웹사이트의 비율(또는 수)을 설정할 수 있습니다.
제한된 릴리스 롤아웃을 설정하면 시스템은 활성 라이선스가 있는 총 활성 웹 사이트를 계산한 다음 그에 따라 릴리스의 새 limit 속성을 설정합니다.
마지막으로 새 릴리스가 있는지 확인하기 위해 웹사이트에서 호출하는 API 끝점을 업데이트하고 다음 논리(의사 코드로)를 도입했습니다.
latest_version = load latest version of product X
If (website is on latest_version)
return “no new version”
If (last_served_update_version of website same as latest_version)
return “no new version”
If (latest_version is limited)
If (latest_version is limited AND uniques >= limit)
return “no new version”
previous_version = load the previous version of product X
If (previous_version is limited too AND uniques <= previous_version.uniques)
If (website not using previous_version AND
last_served_update_version different from previous_version)
return “no new version”
else If (random({true, false}) )
return “no new version”
Set last_served_update_version of website to latest_version
Increment uniques by 1
return latest_version
이 알고리즘은 다음을 보장합니다.
- 릴리스의 노출은 롤아웃의 설정 비율에 따라 제한됩니다.
- 이전 버전이 아직 스테이징되어 있는 경우, 즉 전체 설치 기반에 노출되지 않은 경우 이전에 스테이징된 릴리스를 받은 웹사이트가 최신 스테이징 릴리스에 먼저 노출됩니다.
각 릴리스가 논리적 저장소를 사용하여 설치 기반의 다른 하위 집합으로 이동하도록 하는 WPML의 단계별 출시 아키텍처와 달리 우리의 구현은 임의성에 의존합니다. 따라서 웹 사이트는 두 번의 연속 릴리스 주기에서 두 개의 초기 단계 릴리스를 얻을 수 있습니다. 그러나 이 접근 방식의 이점은 모든 고객에게 전파하는 데 몇 개월, 심지어 몇 년이 걸릴 수 있는 SDK 업데이트를 푸시할 필요 없이 모든 파트너의 고객에게 단계적 출시를 제공할 수 있다는 것입니다.
WordPress의 미래를 위해 단계적 출시가 필수적인 이유는 무엇입니까?
내가 Amir에게 WPML 릴리스 주기를 위한 단계별 출시를 개발하게 된 계기가 무엇인지 물었을 때 그는 이렇게 말했습니다.
3년 전, WordCamp Europe에서 저는 WPML 고객과 대화를 나누며 전반적인 경험에 대한 모든 종류의 피드백을 수집했습니다. 내가 찾은 #1 좌절은 예기치 않게 사이트가 중단될 수 있으므로 고객이 플러그인을 업데이트하는 것을 두려워한다는 것입니다.
아미르 헬저,
OnTheGoSystems(WPML, 도구 집합)의 설립자
나는 그것에 절대적으로 관련이 있습니다.
플러그인 및 테마 업데이트에 관한 Freemius의 내부 정책은… 단순히 하지 마십시오! 두 가지 예외: 알려진 보안 문제가 있거나 사이트에 필요한 최신 버전에서 사용할 수 있는 기능이 있는 경우.
업데이트 정책은 잘못되어 예기치 않은 두통과 시간 낭비를 초래하여 운영 및 일정을 방해하는 업데이트가 여러 번 발생한 후 "혈통으로 작성"되었습니다. 그리고 예, 준비 환경에서 스트레스를 어느 정도 피할 수 있었지만 프로덕션 업데이트를 계속 원했다면 시간과 번거로움을 절약하지 못했을 것입니다.
WordPress는 그 이후로 약간 발전했으며 이제 플러그인 오류에 대한 자동 비활성화 기능이 있습니다. 그러나 테마에는 적용되지 않으며 우리 웹 사이트의 미션 크리티컬 플러그인 비활성화는 여전히 큰 문제입니다.
결론은 내가 플러그인 개발자이자 수천 명의 플러그인 및 테마 개발자가 비즈니스 성장을 돕는 회사의 CEO로서 우리 사이트에서 플러그인이나 테마를 업데이트할 때마다 사이트가 손상되는 것을 우려한다면 그것은 확실히 의미가 있습니다. 대부분의 사용자는 우리 공간의 소프트웨어 업데이트에 자신이 없습니다.
단계적 출시의 부족은 우리와 전체 WP 에코시스템을 뒤로하고 SaaS 기반 경쟁 솔루션에 상당한 이점을 제공합니다. WiX 및 Shopify 사용자는 업데이트에 대해 전혀 생각할 필요가 없습니다! 업데이트는 백그라운드에서 이루어지며 소프트웨어는 항상 최신 상태로 보안 및 기능면에서 최신 상태를 유지합니다.
단계적 출시의 부족은 전체 WP 에코시스템을 유지하고 SaaS 기반 솔루션에 상당한 이점을 제공합니다. WiX 및 Shopify 사용자는 소프트웨어 업데이트에 대해 생각할 필요가 없습니다. 단지 백그라운드에서 발생합니다.Tweet
지난주 State of the Word를 본다면 WordPress의 공동 창립자인 Matt Mullenweg는 최신 소프트웨어의 중요성을 분명히 깨달았습니다. 다음은 WP 업데이트에 대한 Matt의 비전입니다.
... Core에 대한 자동 업데이트를 옵트인할 수 있습니다. 이것은 WordPress를 설정하고 잊어버릴 수 있을 때 기본적으로 자체 유지 관리할 수 있도록 하는 우리 목표의 첫 번째 단계입니다. 그러면 백그라운드에서 자동으로 모든 플러그인, 테마 및 코어가 번거롭지 않게 업데이트됩니다.Tweet
내가 상상할 수 있는 유일한 방법은 WordPress가 "설정 후 잊히게" 되는 것입니다. 소프트웨어 업데이트가 보다 안정적이고 신뢰할 수 있고 이것이 단계적 롤아웃을 통해서만 가능하다면 말입니다.
WordPress.org: 플러그인 및 테마 저장소에 대한 단계적 출시를 도입하는 방법은 다음과 같습니다.
우리의 구현과 유사하게, 두 개의 새로운 메타 옵션이 WordPress.org 데이터베이스의 모든 플러그인 및 테마 릴리스에 추가되어야 합니다: limit 및 uniques .
limit 메타 옵션 편집은 기록된 소유자(및 다른 커미터의 경우)에 대해 고급 보기에 노출될 수 있습니다.
개발자는 모든 릴리스의 노출을 제어하는 방법과 다음 릴리스에 대한 제한을 설정할 수 있는 방법을 갖게 됩니다.
WordPress.org는 WordPress.org에서 업데이트를 받는 모든 웹사이트에 대한 구조화된 데이터를 저장하지 않기 때문에 웹사이트에서 "본" 최신 버전을 WordPress.org 데이터베이스에 저장하는 대신 데이터 저장을 웹사이트에 위임할 수 있습니다. . 이는 업데이트를 확인할 때 'update_plugins' 임시 및 WordPress.org API로 전송되는 데이터가 last_served_update_version 으로 보강되어야 함을 의미합니다.
마지막으로 WordPress.org 업데이트 API 끝점은 Freemius 단계적 출시 구현에 사용한 것과 동일한 논리로 보강할 수 있습니다. wp.org 데이터베이스의 last_served_update_version 에 의존하는 대신 메커니즘은 코어가 웹사이트에서 보낸 값에 의존합니다.
쉽죠?
고용이다 
업데이트 버튼을 누르는 사용자의 자신감을 되찾자
우리 모두는 WordPress가 성공하고 지속적으로 더 크고 더 나은 성장을 하기를 바랍니다!
Gutenberg에 들어가는 리소스가 너무 많기 때문에 WordPress의 리더십은 우리가 기술이 없는 평범한 Joe가 플랫폼에 더 쉽게 접근할 수 있도록 만들어야 한다는 점을 인정하고 있습니다. 문제는 소프트웨어 업데이트가 신뢰할 수 없는 한 Gutenberg와 우리가 사용할 수 있는 모든 놀라운 페이지 빌더를 사용하더라도 기술이 부족한 사람은 첫 업데이트가 깨질 때 Wix로 도망갈 것입니다. 그들을.
EDD의 설립자, Pippin Williamson, WooCommerce CEO, Paul Maiorana 및 WordPress.org 팀에게 전화를 걸고 있습니다. 더 큰 WordPress 커뮤니티를 위해 플러그인 및 테마 생태계를 훨씬 더 안정적으로 만들 수 있는 기회가 있습니다. 사용자가 두려움과 좌절을 덜고 소프트웨어를 안전하게 최신 상태로 유지할 수 있도록 합시다. 단기적으로는 우선 순위가 높지 않은 것처럼 보이지만 장기적으로는 우리 모두가 혜택을 받을 것이라고 확신합니다.