의존성 홍보 전략 : 사일로 또는 조정?

우리는 서로 상호 의존하는 많은 앱과 웹 서비스 (일부 공개 제품, 일부 내부 및 개인 "백엔드")를 보유하고 있습니다. 이러한 구성 요소 각각에는 4 가지 환경이 있습니다 (특정 목적을 수행하는 서버 / 노드 클러스터).

• 비 생산
  • DEV-CI가 푸시 변경을 구축하는 통합 개발 환경; 엔지니어가 로컬에서 재현 할 수없는 찾기 어려운 버그를 해결하는 데 유용
  • QA -격리 된 QA / 테스트 환경
  • DEMO -비즈니스 이해 관계자를위한 안정적인 UAT 환경
• 생산
  • LIVE -라이브 / 프로덕션 환경

코드 승격 : LOCAL(개발자 시스템) => DEV=> QA=> DEMO=> LIVE.

라는 myappRESTful 웹 서비스에 의해 지원되는 응용 프로그램이 있고 myws그 자체는이라는 DB에 의해 지원됩니다 mydb.

현재 우리는 이러한 의존성들 중 " 오케스트레이션 "프로모션 이라고 myapp-dev하는 myws-dev것을 사용하고 mydb-dev있습니다. 마찬가지로을 사용하는 myapp-qa지점을 가리 킵니다 . 동일에 와 .myws-qamydb-qaDEMOLIVE

이 문제는 말,에 나는 변화를 만드는 것이 언제이며 myapp,이 변경하게 저를 필요로 myws하고 mydb도 있습니다. 그러나 각 DEV환경은 종속 환경을 가리 키 므로 DEV이러한 변경 사항을 동시에 예약하고 롤아웃해야합니다. 또한 하나의 빌드가 불안정하거나 깨지면 다른 업스트림 구성 요소가 다운되는 경우가 많습니다. 변경하는 경우 예를 들어 개발자 나누기 뭔가 경우 mydb-dev의 myws-dev및 myapp-dev클러스터는 일반적으로도 불안정해질.

이 문제를 해결하기 위해 "사 일드 (siled) "프로모션 전략 이라고하는 제안을 작성하고 있습니다 . 모든 구성 요소 간 종속성은이 지침을 따릅니다.

• 업스트림 종속성은 DEMO다운 스트림 종속성, 모든 비 프로덕션 환경 ( DEV, QA및 DEMO) 에 대한 환경 에 따라 다릅니다 . 과
• 업스트림 종속성은 LIVE프로덕션 환경의 다운 스트림 종속성에 대한 환경에 따라 다릅니다.

이 규칙을 사용하면 myapp-dev실제로는를 가리킬 myws-demo것 mydb-demo입니다. 마찬가지로 및을 myapp-qa가리킬 수도 있습니다 .myws-demomydb-demo

여기서 찾을 수있는 장점은 빌드 안정화입니다 . DEMO코드가 DEMOon DEV및 에서 엄격하게 테스트하지 않으면 특정 구성 요소 의 환경이 불안정해질 가능성이 훨씬 줄어 듭니다 QA.

만약이 방법으로 찾을 수있는 유일한 단점은, 그입니다 DEMO특정 구성 요소에 대한 휴식을 수행, 모든 모든 업스트림 의존성에 대한 비 생산 환경이 갑자기 파손됩니다. 하지만이 때문에에서 수행 된 시험의 매우 드물게 발생하지 것을 반대 것 DEV하고 QA.

이것은있다 얻었다 (매우 똑똑하고 자신보다 경험) 많은 개발자들이 해결 한 것을 문제,이 문제와 그 솔루션은 이미 그들에게 이름을 가지고 있다면 놀라지 않을 것이다 (나는 조율 / 사일로 호출하고있는 무슨 외에). 그래서 나는 묻습니다. 사일로의 프로모션 전략의 장점이 단점보다 더 중요합니까? 여기서 간과 할 수있는 단점은 무엇입니까?

내가 당신의 게시물을 올바르게 읽고 있다면,이 제안이 실제로 의심되는 문제 중 하나를 해결하는 것처럼 보이지 않습니다.

myapp와 같이 변경할 때마다 myws와 mydb도 변경해야합니다. 그러나 각 DEV 환경은 종속성의 DEV 환경을 가리 키므로 이러한 변경 사항을 동시에 예약하고 롤아웃해야 함을 의미합니다.

"사일로 홍보 전략"은 이것이 더 나빠질 것 같습니다. myapp v2, myws v2 및 mydb v2가 DEV에만 있고 myapp v2가 mydb v2를 사용하여 충돌하지 않으면 DEV에서 myapp v2를 실행하려고하면 mydb v1 DEMO가 발생하고 충돌이 발생합니다. 기본적으로 사일로를 지속적으로 무시하거나 myapp v2 작업을 시작하기 전에 항상 mydb v2를 배포하여 강제로 배포해야합니다. 더 중요한 것은 DEV에서 mydb v2를 테스트하지 않으므로 DEMO에서 중단 될 때까지 찾지 못하면 정사각형으로 돌아갑니다.

어느 정도까지는 워크 플로 설정 방법에 관계없이 설명하는 문제가 불가피하지만 최소화 할 수 있습니다. 요령은 mydb와 myws 사이의 인터페이스 (myws와 myapp 사이의 인터페이스)를 엄격하게 정의 하고 해당 인터페이스의 모든 업데이트가 이전 버전과 완전히 호환되도록하는 것 입니다. 내 업무에는 앱과 서비스 간의 인터페이스를 정의하는 XML 스키마가 있으며 많은 내부 도구를 사용하면 해당 스키마에 호환되지 않는 업데이트를 만들 수 없습니다.

또한 하나의 빌드가 불안정하거나 깨지면 다른 업스트림 구성 요소가 다운되는 경우가 많습니다. 예를 들어 개발자가 mydb-dev를 변경할 때 문제가 발생하면 myws-dev 및 myapp-dev 클러스터도 일반적으로 불안정 해집니다.

이것은 심각한 문제처럼 들리지만 배포 문제는 아닙니다. 손상된 데이터베이스는 서비스와 앱이 제대로 작동하지 못하게하지만 "불안정한"상태가되어서는 안됩니다. 그들은 어떤 종류의 오류 메시지를 반환해야하므로 dev에서 myapp를 실행하는 사람은 단순히 충돌하는 대신 "오늘 죄송합니다. 데이터베이스에 문제가 있습니다"라는 메시지가 표시됩니다.

문제가있는 데이터베이스가 손상된 경우 이러한 문제가 발생하는 경우 "mydb DEV가 손상되었습니다."라는 "임시 사일로"시스템을 설정하면 모든 myws DEV 쿼리를 mydb DEMO로 라우팅 할 수 있습니다. 시간 인". 그러나 이것은 mydb DEV가 다시 정상적으로 작동 할 때까지 임시 수정 을 수행하는 방법이어야 합니다. 기본적으로 모든 것이 "사일로"인 경우, 아무도 mydb DEV에 대해 전혀 실행하지 않기 때문에 위에서 설명한 문제가 발생합니다.

나는 당신의 제안을 어떻게 든 오해하고있을 것 같지만,이 대답이 적어도 오해 된 것이 무엇인지, 그리고 그것을 가장 잘 표현하는 방법을 분명히하기를 바랍니다.