출처
Blue-green deployment
A blue-green deployment reduces risk and downtime by running two identical environments. These environments are called blue and green. At any time, only one of the environments is live. A blue-green deployment typically involves a router or load balancer that helps control the flow of traffic.
'blue-green deployment'는 두 개의 동일한 환경을 실행하여 위험과 다운 타임을 줄입니다. 이러한 환경을 blue and green이라고합니다. 언제든지 환경 중 하나만 활성화됩니다. blue-green deployment에는 일반적으로 트래픽 흐름을 제어하는 데 도움이되는 라우터 또는로드 밸런서가 포함됩니다.
Let's say blue is live. As we prepare a new release, we do our final tests in the green environment. After the software is working in the green environment, we just switch the router so that all incoming requests go to the green environment.
Blue-green deployment also gives us a fast way to do a rollback. If anything goes wrong in the green environment, then we just switch the router back to the blue environment.
파란색이 라이브라고 가정 해 보겠습니다. 새 릴리스를 준비하면서 녹색 환경에서 최종 테스트를 수행합니다. 소프트웨어가 녹색 환경에서 작동 한 후에는 들어오는 모든 요청이 녹색 환경으로 이동하도록 라우터를 전환하기 만하면됩니다.
블루-그린 배포는 롤백을 수행하는 빠른 방법을 제공합니다. 녹색 환경에서 문제가 발생하면 라우터를 파란색 환경으로 다시 전환합니다.
Canary releases
A canary release is a way to identify potential problems early without exposing all users to the issue. The idea is that we expose a new feature to only a small subset of users before we make it available to everyone.
카나리아 출시는 모든 사용자를 문제에 노출시키지 않고 잠재적 인 문제를 조기에 식별하는 방법입니다. 모든 사람이 사용할 수 있도록하기 전에 새로운 기능을 소수의 사용자에게만 노출하는 것이 아이디어입니다.
In a canary release, we monitor what happens when we release the feature. If the release has problems, then we apply a fix. After the canary release is known to be stable, we move it to the actual production environment.
카나리아 릴리스에서는 기능을 릴리스 할 때 어떤 일이 발생하는지 모니터링합니다. 릴리스에 문제가있는 경우 수정 사항을 적용합니다. 카나리아 릴리스가 안정적인 것으로 확인되면 실제 프로덕션 환경으로 이동합니다.
Feature toggles
Feature toggles let us "flip a switch" at runtime. We can deploy new software without exposing any other new or changed functionality to our users.
In this deployment pattern, Mara and I build new features behind a toggle. When a release occurs, the feature is "off" so that it doesn't affect the production software. Depending on how we configure the toggle, we can flip the switch to "on" and expose it how we want.
기능 전환을 사용하면 런타임에 '전환'을 할 수 있습니다. 새로운 기능이나 변경된 기능을 사용자에게 노출하지 않고도 새로운 소프트웨어를 배포 할 수 있습니다.
이 배포 패턴에서 Mara와 저는 토글 뒤에 새로운 기능을 구축합니다. 릴리스가 발생하면 기능이 "해제"되어 프로덕션 소프트웨어에 영향을주지 않습니다. 토글을 구성하는 방법에 따라 스위치를 "켜짐"으로 전환하고 원하는 방식으로 노출 할 수 있습니다.
For example, we could expose the feature first to a small number of users to see how they react. That random sample of users sees the feature. Or we could just let the feature go live to everyone.
But this deployment pattern might benefit Mara and me more than anyone else. The big advantage to the feature toggles pattern is that it helps us avoid too much branching. Merging branches can be painful.
예를 들어, 소수의 사용자에게 먼저 기능을 노출하여 그들이 어떻게 반응하는지 볼 수 있습니다. 사용자의 무작위 샘플이 기능을 봅니다. 아니면 모든 사람에게 기능을 제공 할 수도 있습니다.
그러나이 배포 패턴은 다른 누구보다 Mara와 저에게 더 많은 혜택을 줄 수 있습니다. 기능 전환 패턴의 가장 큰 장점은 너무 많은 분기를 방지하는 데 도움이된다는 것입니다. 분기를 병합하는 것은 고통 스러울 수 있습니다.
Dark launches
A dark launch is similar to a canary release or switching a feature toggle. Rather than expose a new feature to everyone, in a dark launch we release the feature to a small set of users.
다크 출시는 카나리아 출시 또는 기능 전환 전환과 유사합니다. 모든 사람에게 새로운 기능을 공개하는 대신 어두운 출시에서 소규모 사용자에게 기능을 출시합니다.
Those users don't know they're testing the feature for us. We don't even highlight the new feature to them. That's why it's called a dark launch. The software is gradually or unobtrusively released to users so we can get feedback and can test performance.
이러한 사용자는 우리를 위해 기능을 테스트하고 있다는 사실을 모릅니다. 우리는 그들에게 새로운 기능을 강조하지도 않습니다. 이것이 다크 런칭이라고 불리는 이유입니다. 소프트웨어는 사용자에게 점진적으로 또는 눈에 띄지 않게 릴리스되므로 피드백을 받고 성능을 테스트 할 수 있습니다.
A/B testing
A/B testing compares two versions of a webpage or app to determine which one performs better. A/B testing is like an experiment.
A / B 테스트는 웹 페이지 또는 앱의 두 가지 버전을 비교하여 어떤 버전이 더 나은지 결정합니다. A / B 테스트는 실험과 같습니다.
In A/B testing, we randomly show users two or more variations of a page. Then we use statistical analysis to decide which variation performs better for our goals.
A / B 테스트에서는 사용자에게 두 개 이상의 페이지 변형을 무작위로 보여줍니다. 그런 다음 통계 분석을 사용하여 목표에 더 적합한 대안을 결정합니다.
Progressive-exposure deployment
Progressive-exposure deployment is sometimes called ring-based deployment. It's another way to limit how changes affect users while making sure that those changes are valid in a production environment.
Rings are basically an extension of the canary stage. The canary release releases to a stage to measure effect. Adding another ring is essentially the same idea.
점진적 노출 배포를 링 기반 배포라고도합니다. 변경 사항이 프로덕션 환경에서 유효한지 확인하면서 변경 사항이 사용자에게 미치는 영향을 제한하는 또 다른 방법입니다.
반지는 기본적으로 카나리아 단계의 확장입니다. 카나리아 릴리스는 효과를 측정하기 위해 단계로 릴리스됩니다. 다른 반지를 추가하는 것은 본질적으로 같은 생각입니다.
In a ring-based deployment, we deploy changes to risk-tolerant customers first. Then we progressively roll out to a larger set of customers.
링 기반 배포에서는 먼저 위험을 허용하는 고객에게 변경 사항을 배포합니다. 그런 다음 더 많은 고객에게 점진적으로 배포합니다.