종속성은 언제 업데이트해야합니까?

우리는 두 개의 다른 코드 기반 (Android 및 Node.js 웹앱)으로 두 가지 주요 종속성 관련 위기를 겪었습니다. Android 저장소는 Flurry에서 Firebase로 마이그레이션해야했으며 Google Play 서비스 라이브러리를 4 가지 주요 버전으로 업데이트해야했습니다 . 프로덕션 스택 (시더)이 더 이상 사용되지 않고 시더 -14로 업그레이드해야하는 Heroku 호스팅 노드 앱에서도 비슷한 일이 발생했습니다. PostgreSQL 데이터베이스도 9.2에서 9.6으로 업데이트해야했습니다.

이러한 앱의 각 종속성은 거의 2 년 동안 오래되었고, 일부는 더 이상 사용되지 않고 '일몰'기간에 이르렀을 때 앱 을 업데이트하거나 교체 하는 데 큰 어려움을 겪었습니다. 지난 한 달 동안 30 시간 이상을 보냈으며 두 번의 모든 갈등과 깨진 코드를 천천히 해결했습니다.

분명히 물건을 2 년 동안 놓아 두는 것은 너무 길다. 특히 Heroku와 같은 플랫폼 공급자를 사용하는 경우 기술이 빠르게 이동합니다. 우리가 본격적인 테스트 스위트와 Travis CI와 같은 CI 프로세스를 가지고 있다고 가정합시다. 예를 들어, 업그레이드 후 기능이 제거되어 사용중인 경우 테스트가 실패합니다.

얼마나 자주 종속성 업데이트해야하거나 할 때 종속성을 업데이트해야 하는가? 우리는 강제로 업데이트했기 때문에 어떤 선제 적 접근 방식이 더 좋을 것 같습니다 . 부 버전이 출시되면 업데이트해야합니까? 메이저 버전? 업데이트가있는 경우 매월? 모든 비용으로 방금 경험 한 것과 같은 상황을 피하고 싶습니다.

추신-개인 Rails 프로젝트 중 하나 인 Gemnasium 이라는 서비스를 사용하여 보안 취약점과 같은 알림을받을 수 있도록 종속성을 추적합니다. 훌륭한 서비스이지만 언급 한 프로젝트의 종속성을 수동으로 확인해야합니다.

다음과 같은 경우 일반적으로 종속성을 업그레이드해야합니다.

1. 필수입니다
2. 그렇게하는 이점이 있습니다
3. 그렇게하지 않으면 불리하다

(이들은 상호 배타적이지 않습니다.)

동기 부여 1 ( "필요한 경우")이 가장 시급한 동인입니다. 당신이 의존하는 어떤 컴포넌트 나 플랫폼 (예 : Heroku)은 그것을 요구하기 때문에 당신은 줄을서야합니다. 필요한 업그레이드는 종종 다른 선택에서 계단식으로 진행됩니다. PostgreSQL 버전으로 업그레이드하기로 결정했습니다. 이제 드라이버, ORM 버전 등을 업데이트해야합니다.

귀하 또는 귀하의 팀이이를 수행 할 때의 이점을 인식하기 때문에 업그레이드하는 것이 더 부드럽고 선택 사항입니다. 더 많은 판단 요청 : "새로운 기능, 능력, 성능, ... 노력과 탈퇴의 가치가 있을까요?" Olden Times에서는 선택적 업그레이드에 대한 강한 편견이있었습니다. 그들은 수동적이고 힘들었고 샌드 박스 에서 시험해 볼 수있는 좋은 방법이 없었습니다.가상 환경 또는 업데이트가 작동하지 않는 경우 업데이트를 롤백하고 업데이트가 "애플 카트를 화나게하지"않았는지 확인하기위한 빠른 자동 테스트가 없었습니다. 요즘은 훨씬 더 빠르고 공격적인 업데이트주기에 대한 편견입니다. 민첩한 방법은 시도하는 것을 좋아합니다. 자동화 된 설치 프로그램, 종속성 관리자 및 저장소는 설치 프로세스를 빠르고 거의 보이지 않게합니다. 가상 환경과 유비쿼터스 버전 제어 기능으로 분기, 포크 및 롤백이 쉬워집니다. 자동화 된 테스트를 통해 업데이트를 시도한 다음 "효과가 있었습니까? 문제가 있습니까?" 편견은 "파산하지 않으면 해결하지 말 것"에서 "조기 업데이트, 자주 업데이트"로 도매로 전환했다

동기 부여 3이 가장 부드럽습니다. 사용자 스토리는 "배관"에 관심이 없으며 "현재 인프라보다 N 릴리스 이하의 인프라를 유지하십시오"라고 언급하지 않습니다. 버전 드리프트의 단점 (대략 곡선 뒤의 하락과 관련된 기술적 부채)은 조용히 침해 된 후 종종 파손을 통해 발표됩니다. "죄송합니다. 해당 API는 더 이상 지원되지 않습니다!" 애자일 팀 내에서도 주어진 스프린트 또는 릴리스를 완료하는 데 중추적 인 것으로 보이지 않을 때 점진적 동기를 부여하고 구성 요소의 신선도를 유지하는 것이 어려울 수 있습니다. 아무도 업데이트를 옹호하지 않으면 업데이트되지 않을 수 있습니다. 그 휠은 부러 질 때까지 또는 부러 질 때까지 삐걱 거리지 않을 수 있습니다.

실용적인 관점에서 팀은 버전 드리프트 문제에 더 많은주의를 기울여야합니다. 2 년이 너무 깁니다. 마법이 없습니다. 그냥 "지금 지불하거나 나중에 지불"의 문제입니다. 버전 드리프트 문제를 점진적으로 해결하거나 몇 년마다 더 큰 충격을 겪습니다. 일부 플랫폼 충돌이 엄청 나기 때문에 증분을 선호합니다. 더 이상 작동하지 않는 주요 API 또는 플랫폼은 하루, 주 또는 월을 실제로 망칠 수 있습니다. 저는 1 년에 1-2 번 정도 신선도를 평가하고 싶습니다. 리뷰를 명시 적으로 예약하거나 Python, PostgreSQL 및 node.js와 같은 주요 구성 요소의 상대적으로 매년 업데이트주기에 의해 유기적으로 트리거되도록 할 수 있습니다. 구성 요소 업데이트로 인해 팀이 매우 강력하게 작동하지 않으면 최신 릴리스에서 최신 정보를 확인하고, 자연 프로젝트 고원에서 또는 모든 k 릴리스도 작동 할 수 있습니다. 보다 규칙적인 케이던스에서 버전 드리프트 수정에주의를 기울이는 것은 무엇이든 상관 없습니다.

라이브러리는 업데이트가 필요할 때 업데이트해야합니다. 즉, 업데이트 할 때 아무런 가치가 없다면 그렇게해서는 안됩니다.

특정 경우에는 오래된 기술 스택에서 새로운 기술 스택으로 마이그레이션하고 있었으므로 종속성을 업데이트해야했습니다. 바로 그 순간이 종속성을 업데이트 할 올바른 시간입니다.

시간이 지남에 따라 종속성을 업데이트 한 경우 "지금 두통이 발생하지 않기"위해 반환 값이없는 작업 시간 (코딩)에 많은 시간을 투자해야했습니다. 그리고 마지막 업데이트 (현재하고있는 업데이트이지만 4 대신 1 개의 주요 버전을 업데이트)를 할 때 어딘가에 두통이있을 수 있습니다 (결국 주요 버전은 변경 사항을 의미합니다). 그래서 당신이 올바른 길을 가고 있다고 생각합니다.

그러나 마이그레이션하기가 너무 어렵고 리팩터링을 많이해야하는 경우 코드베이스에 문제가있을 가능성이 있습니다. 안드로이드 프로젝트가 코드 구조 측면에서 전체 아키텍처를 갖지 않는 것이 일반적입니다. Dagger 2 와 같은 우수한 의존성 주입 프레임 워크와 SOLID 와 같은 몇 가지 소프트웨어 엔지니어링 원칙 은 동일한 동작 / 요구 사항을 유지하면서 코드 구현을보다 쉽게 ​​변경할 수있게 해줍니다.

또한 우리는 리팩토링을하고 있기 때문에 이런 종류의 작업을 할 때 많은 도움이 될 것이므로 단위 테스팅에 대해 조금 읽어보십시오.

패키지 관리 도구 (예 : npm, NuGet)를 사용하고 포괄적 인 자동화 된 테스트 스위트를 사용하는 경우 종속성을 업그레이드하는 것이 노력이 적은 활동이어야합니다. 간단히 패키지를 업그레이드하고 테스트 스위트를 실행하고 문제가 있는지 확인하십시오. 그런 다음 롤백하고 작업 항목을 제기하여 문제를 조사하고 수정하십시오.

종속성 업그레이드 비용이 낮 으면 최신 상태로 유지할 가치가 있습니다.

• 업그레이드에 문제가있는 경우 업스트림 변경이 필요한 경우 나중에보다 빨리 알고 싶습니다.
• 마지막 순간까지 종속성 업그레이드를 유지한다는 것은 종종 크런치 시간에 보안 업그레이드에 대한 응답으로 업그레이드를 수행한다는 것을 의미합니다. 종속성을 유지한다는 것은 그러한 노력을 기울이는 시간을 제어하고 바쁘지 않은 시간에 업그레이드를 수행 할 수 있음을 의미합니다.
• 최신 버전은 더 나은 문서화, 사용하기 쉬운 API, 버그 수정과 같이 생산성이 향상 될 수 있습니다 (반대의 경우도 가능).

종속성을 업그레이드하는 데 노력이 적지 않은 경우 (예 : 업그레이드를 수동으로 테스트해야하거나 알려진 문제 / 변경 사항이 있기 때문에) 다른 작업에 대한 장단점을 고려해야합니다. 오래된 의존성은 일종의 저금리 기술 부채이므로 그에 따라 처리해야합니다.

지원되는 대안이 아닌 경우 이전 버전의 종속성을 의도적으로 사용하는 릴리스를 수행하지 마십시오.

즉, V1을 사용 중이고 여전히 지원되는 경우 최신 버전의 v1을 계속 사용할 수 있습니다.

최신이 아닌 유일한 경우는 다음과 같습니다.

A : 한동안 출시를하지 않았습니다.

B : v1을 오랫동안 사용하여 더 이상 지원되지 않습니다.

업데이트는 사유로 출시되며 여기에는 보안 수정 사항이 포함되어 있습니다.

종속성의 새 버전이 나오면 릴리스도 수행해야합니다

나는 그것이 라이브러리에 어느 정도 의존해야한다고 생각하지만, 나는 비슷한 의존성 두통을 겪었다.

상식에 따르면 메이저 버전은 업그레이드하기에 적절한시기이며 심각한 결함을 해결하거나 상당한 이점을 포함하는 마이너 버전이이를 대체한다고합니다.

때로는 유지 관리가 필요하거나 미션 크리티컬 응용 프로그램을 배포 취소해야하는 모든 응용 프로그램에서 작업 할 수있는 사치가없는 경우도 있지만 결국에는 물릴 것이며 예방 조치는 종종 치료법을 능가합니다!

라이브러리는 변경에 소요 된 작업을 보상하기 위해 소프트웨어가 사용할 이점을 제공 할 때 업데이트해야합니다.

사소한 라이브러리 버전 업그레이드조차도 앱에 불일치를 일으키거나 삽입 할 수 있습니다. 이러한 관점에서 사소한 변경은 없습니다.

오래된 라이브러리를 사용하는 데 부끄러움이 없습니다. 변화가 필요할 때 고통 스러울 수 있지만 그것은 일의 일부입니다.