개발자에서 제품에 이르기까지 구성 변경 사항을 효과적으로 추적

이 질문은 스프링 부트 서비스를 예로 들어 설명하지만 어떤 기술이든 가능합니다.

다음을 가정합니다.

• 환경 (dev / QA / prod)은 다른 팀이 소유합니다. 이는 개발자가 제품 구성에 액세스 할 수 없어야 함을 의미합니다.
• 구성 (application.properties)은 외부화되어 있습니다 (즉, 바이너리의 일부가 아님).
• 각 환경에 동일한 바이너리 / 패키지 (service.jar)가 배포되고 자동 배포로 제어됩니다.

이진 아티팩트 (service.jar)에 대한 변경 사항이 각 환경에 자동으로 전파되는 동안 구성 변경 사항에는 여전히 수동 개입이 필요하며, 이는 각 환경에서 비 동기화되어야합니다.

예를 들어, dev 팀이 환경의 application.properties에 몇 가지 키-값 쌍을 추가한다고 가정 해 봅시다. 이러한 새 키를 기록하는 가장 좋은 방법은 ops 팀에서 배포가 발생할 때 정확히 어떤 키를 추가해야하는지 알 수 있으므로 새 서비스를 시작하고 키가 없어서 실패 할 가능성을 최소화 할 수있는 방법은 무엇입니까?

수동 단계가 필요하다는 것을 알고 있지만 사람들이이 문제를 어떻게 처리하고 가장 효과적인 방법을 찾는 지 알고 싶습니다.

이것은 주로 의사 소통 문제이지만 간단한 기술 및 조직적 조치로 오류를 줄일 수 있습니다. 먼저, 구성 파일의 모든 항목과 쉽게 액세스 할 수있는 예제 또는 "기본"구성 파일에 대한 고품질 문서를 ​​제공해야합니다. 예제 파일 은 prod 팀이 직접 변경하지 않기 때문에 각 환경에 자동으로 배포 할 수 있습니다.

다음으로, 각각의 새로운 릴리스와 함께 중요한 변경 사항이 문서화 된 변경 로그를 제공하십시오. 시스템이없는 경우 시스템 작동을 방해 할 수있는 구성 변경은 항상 중요하므로 정보가 있는지 확인하십시오.

예를 들어 dev 팀이 환경의 application.properties에 몇 가지 키-값 쌍을 추가한다고 가정 해 보겠습니다. 이러한 새 키를 기록하는 가장 좋은 방법은 ops 팀에서 배포가 발생할 때 정확히 어떤 키를 추가해야하는지 알 수 있으므로 새 서비스를 시작하고 키가 없어서 실패 할 가능성을 최소화 할 수 있습니까?

실패의 위험을 줄이는 가장 좋은 방법 은 새 키 가 필요한 방식으로 응용 프로그램을 변경하지 않도록하는 것이므로 가능하면 응용 프로그램은 이전 구성 파일과 역 호환되어야합니다. 종종 새 키가 누락 된 경우에 대해 기본 제공 기본값을 제공하여 애플리케이션이 합리적인 방식으로 작동 할 수 있습니다.

그러나 이것이 가능하지 않으면 시스템은 키가 없을 때 새 서비스가 시작되지 않는 이유를 prod 팀이 쉽게 찾을 수 있도록해야합니다. 이 이야기 명확한 오류 메시지,해야 정확히 키에서 누락 된 파일을 , 필요한 경우 어디에서 정보를 찾기 위해 이 키에 대한 의미있는 항목에 대한 누락 된 키 또는 힌트 또는 예 약을.

구성이 복잡하고 수동 편집이 오류가 발생하기 쉬운 방식으로 형식이 변경되면 구성을 편집하고 최신 버전으로 마이그레이션하기위한 도구를 제공하는 것도 고려할 수 있습니다.

예를 들어, Firefox 웹 브라우저를 사용하고 있으며 각각의 새 릴리스 (자동으로 제공됨)에서 "about : config"페이지에서 확인할 수있는 로컬 구성에 특정 항목이 추가됩니다. 이것은 "프로덕션"환경의 구성과 비슷합니다. 전체 구성은 이전 버전과 완전히 호환되므로 브라우저의 새 릴리스가 있기 때문에 구성에 새 키를 수동으로 추가 할 필요가 없습니다. 그리고 거기에서 무언가를 변경하고 싶을 때 (이전 버전의 일부가 아닌 새로운 항목 일 수도 있음) 도구 / 옵션 메뉴 또는 "about : config"페이지를 사용하여 항목과 일부를 찾을 수 있습니다 종류의 문서. 따라서 시스템을 비슷한 방식으로 구현하는 것이 좋습니다.

한때 일했던 곳에서도 비슷한 문제가있었습니다. 프로덕션 구성은 빌드 팀에 의해 제어되었으며 코드 리포지토리에서만 액세스 할 수있었습니다. dev, qa, test 등 구성은 모든 사람이 볼 수 있습니다.

귀하의 예에서 개발자는 파일을 로컬로 업데이트하고 소스 제어에 체크인 한 다음 누군가 빌드 팀에 구성 파일을 체크 아웃하고 배치했지만 다시 컴파일 하지 않은 새 "구성 만"빌드를 수행하도록 요청합니다. 전체 애플리케이션을 재배치하십시오.

적절한 시간에 다른 환경에 대한 구성 파일을 업데이트하는 것은 팀 구성원의 책임입니다. 프로덕션을 위해 업데이트해야 할 때 빌드 팀은 개발자 팀의 명시 적 요청을 통해 파일을 업데이트해야했지만 일반적으로 요청은 단순히 "app.config 파일을 QA1에서 PROD로 복사"와 비슷했습니다. 비밀번호와 같은 민감한 항목은 별도의 구성 파일에 있으며, 다시 빌드 팀만이 프로덕션 비밀번호 파일에 액세스 할 수 있습니다. 차이는 개발자가 일반적으로 한 것이 었 하지프로덕션 비밀번호가 없었기 때문에 비밀번호 파일에 대한 변경을 요청합니다. 빌드 팀에게 업데이트를 요청하는 유일한 시간은 새 서비스에 대한 새 비밀번호를 추가 할 때였습니다. 그리고 개발자도 프로덕션 비밀번호를 모르고 파일에 추가 할 키만 알고있을 것입니다 (예 : "newService2.password").

많은 것을 관리하는 데 사용 된 기술은 Jenkins였습니다. Jenkins를 통해 빌드를 요청하고 예약하는 데 사용되는 사내 도구도있었습니다.