타사 라이브러리를 최신 상태로 유지하는 방법은 무엇입니까?

10 개의 라이브러리에 의존하는 프로젝트가 있고 프로젝트 트렁크 내에서 해당 라이브러리의 모든 버전을 자유롭게 사용할 수 있다고 가정 해 봅시다. 최신 버전부터 시작합니다. 그런 다음 각 라이브러리는 한 달에 한 번 (평균) 업데이트를받습니다. 이제 트렁크를 최신 상태로 유지하려면 3 일마다 라이브러리 참조를 업데이트해야합니다.

이것은 분명히 너무 많습니다. 일반적으로 버전 1.2.3이 버전 1.2.2의 드롭 인 대체품이지만 테스트 없이는 알 수 없습니다. 단위 테스트로는 충분하지 않습니다. DB / 파일 엔진 인 경우 이전 버전으로 작성된 파일에서 제대로 작동하는지 확인해야하며 그 반대의 경우도 마찬가지입니다. GUI와 관련이 있으면 모든 것을 시각적으로 검사해야합니다. 등등.

이것을 어떻게 처리합니까? 몇 가지 가능한 접근 방식 :

• 고장 나지 않았다면 고치지 마십시오 . 만큼 라이브러리의 현재 버전을 그대로 사용하면 응용 프로그램, 라이브러리 공급 업체에 업데이트를 게시하는 빈도에 상관없이 사용할 때 그것으로 통지 아무것도 잘못하지 않습니다. 작은 증분 변경은 낭비입니다.
• 변경 사항을 작게 유지하려면 자주 업데이트하십시오. 어떤 경우 든 언젠가 업데이트해야하므로 여러 버전으로 건너 뛰어 잠재적 인 문제가 누적되는 대신 문제를 쉽게 해결할 수있는 초기에 문제를 발견 할 수 있도록 자주 업데이트하는 것이 좋습니다.
• 그 사이에 뭔가가 있습니다. 스위트 스팟이 있습니까?

나는 여기에 "필요하지 않으면 업데이트하지 마십시오"라는 답변의 수에 놀랐습니다. 나는 그것을 해왔고 단기적으로는 쉽지만 장기적으로는 지옥처럼 타 버린다. 더 빈번하고 작은 업데이트는 가끔 큰 업데이트보다 관리하기가 훨씬 쉽고 새 기능, ​​버그 수정 등의 이점을 더 빨리 얻습니다.

라이브러리 변경이 코드 변경보다 테스트하기가 더 어렵다는 아이디어를 구입하지 않았습니다. 코드베이스를 변경하고 있으므로 커밋하기 전에, 그리고 릴리스하기 전에 더 깊이 검증해야합니다. 그러나 코드를 변경하기 때문에 이미 프로세스가 있어야합니다!

2 ~ 4 주 길이의 반복 작업을하는 경우 반복 작업보다 라이브러리가 조금 완화 된 경우 시작 후 가능한 한 빨리 라이브러리를 한 번 업데이트하는 것이 좋습니다. 마감일이 지남에 따라 프로젝트에 변화를 흡수 할 수있는 용량이 더 많습니다. 누군가 (또는 페어 프로그래밍을하는 경우 페어)를 앉히고 업데이트 된 라이브러리를보고 각 라이브러리를 가져 와서 재구성 및 테스트를 시도하십시오. 아마도 매번 반나절 씩 예산을 책정하십시오. 문제가 해결되면 변경 사항을 확인하십시오 (라이브러리를 소스 제어 상태로 유지한다고 가정합니다. 그렇지 않은 경우 제어 된 방식으로 변경 사항을 어떻게 전파할지 모르겠습니다). 테스트가 완전히 수동적 인 경우보다 자동화 된 테스트를 사용하는 경우 훨씬 쉬울 것입니다.

이제 문제는 업데이트로 인해 문제가 발생하면 해결하는 데 시간이 걸리나요? 나는 후자를 향한 제안을 제안한다. 한 시간 안에 고칠 수 있다면 업데이트를해야하지만 업데이트를 통합하는 데 상당한 노력이 필요한 경우 자체 개발 작업으로 높이고 다른 예측처럼 우선 순위를 정하고 일정을 계획해야합니다. 매우 중요한 수정 또는 개선이 이루어지지 않는 한 우선 순위가 낮아지고 절대로 그럴 수는 없습니다. 그러나 다음 번 반복 업데이트 날짜가 다가올 때까지는 문제가 자체적으로 해결되었을 수 있습니다. 그렇지 않더라도 적어도 지금은 업데이트 경로에 장애물이 있다는 것을 알고 있으며 놀라지 않을 것입니다.

해당 길이의 반복을 수행하지 않으면 매월이 아닌 업데이트에 대한 일종의 독립 실행 일정을 설정합니다. 월별 상태 검토 또는 건축위원회 회의와 같이 묶을 수있는 다른 프로젝트 리듬이 있습니까? 월급 날? 피자의 밤? 보름달? 어쨌든 6-18 개월마다 한 번에 모든 항목을 업데이트하려고하면 고통스럽고 민첩 해지기 때문에 기존 릴리스주기보다 훨씬 짧은 것을 찾아야합니다.

말할 것도없이, 릴리스 전에 안정화 브랜치를 수행하면이 정책을 적용하지 않을 것입니다. 여기서 중요한 수정 사항을 얻기 위해 라이브러리 만 업데이트합니다.

평가합니다.

• 먼저 해당 라이브러리에 대해 제기 한 버그를 찾아서 수정되었는지 확인합니다.
• 두 번째로 lib에서 도움이 될 수있는 다른 버그 수정 (아마도 가능한 경우)을 찾습니다.
• 세 번째로 lib / API에서 개선 된 부분을 찾은 다음 코드를 변경하여 그 이점과 이점을 활용할 때의 영향을 조사합니다. 나는 과거의 업그레이드 라이브러리에서 새로운 기능을 실제로 사용하지 않고 너무 자주 사용했습니다.

그런 다음 기존 라이브러리에 머무르는 것에 대해 모든 것을 측정합니다.

항상 테스트하십시오. 단위 / 통합 테스트를 통해 큰 회귀가 발생하지 않기를 바랍니다.

타사 라이브러리의 주요 문제점은 프로덕션 환경에 들어가기 전에 업데이트 할 때 응용 프로그램을 다시 테스트해야한다는 것입니다. 따라서 라이브러리를 업데이트해야하는보고 된 버그가 없으면 완전한 품질 보증주기를 수행 할 시간이 될 때까지 버그를 만지지 마십시오.

일반적으로 새 버전을 출시 할 때 수행됩니다.

그러나 개발 브랜치에서 라이브러리를 업데이트하고 자동으로 업데이트 할 수있는 연속 빌드를위한 테스트 스위트가 있다고 제안합니다. 이렇게하면 문제가 발생했을 때 조기에 발견 할 수 있으므로 프로젝트에 버그 보고서를 제출할 수 있습니다.

svn 공급 업체 분기에 설명 된대로 부분적으로 . 여기에 설명 된 절차는 오픈 소스 타사 라이브러리를 오랫동안 사용하고 필요에 맞게 변경하기 위해 매우 유용합니다.

릴리스 직전 또는 직후에 프로젝트의 모든 라이브러리를 업데이트하는 것에 대해 생각할 것입니다. 그러나 10 개 또는 15 개가 넘는 라이브러리를 사용하는 경우이 기능이 제대로 작동하지 않을 수 있습니다.이 경우 일종의 업데이트 확인 메커니즘이 크게 도움이됩니다. 이것의 장점은 라이브러리 테스트에 전념하고 한 번에 모든 문제를 해결할 수 있다는 것입니다. 또한 모든 단일 라이브러리의 업데이트를 지속적으로 추적 할 필요가 없으며 특정 날짜에 업데이트가 있는지 확인하면됩니다.

또한 개발자 브랜치에서도 모든 종류의 자동 업데이트 기능에 반대합니다. 라이브러리 자동 업데이트 자체로 인해 프로젝트가 중단 된 작업을 수행하거나 갑자기 다른 것으로 대체 된 API 사용에 대한 감가 상각 경고가 갑자기 발생하면 실망 스럽습니다.

업데이트에서 무엇을 정말로 원하십니까? 대부분의 보안 수정 프로그램은 실제로 수정 형식의 간단한 패치입니다.

• 임의의 코드를 버퍼의 사용되지 않은 공간에 복사 할 수있는 하나의 오류로 인해 꺼짐
• 매달려있는 포인터 또는 정의되지 않지만 결정적 행동을 유발하는 다른 것
• 일종의 DoS를 허용하는 버그
• 실수로 개인 데이터 스누핑을 쉽게 만드는 버그
• 수학 실수
• 관리자는 자신이해서는 안되는 것들을 만집니다 (데비안 SSL 버그, 누구?)

지난 5 년 동안 대부분의 CVE를 살펴보면 공개 라이브러리를 사용하는 경우이를 수정하는 패치는 일반적으로 매우 사소한 것입니다.

그런 다음 원하는 실제 버그 수정이있을 수 있지만 이미 수정했습니다. 손상되지 않은 경우 수정하지 마십시오.

마지막으로, 당신은 새로운 기능 .. 그리고 아마도 더 이상 사용되지 않는 기능을 가지고 있습니다. 해당 릴리스 노트와 차이점을주의 깊게 검토해야합니다. 다른 많은 것들이 의존하는 API를 깨뜨려도 사용할 수 있습니까? 그렇다면 수술의 시간입니다 .. 만약 아니라면, 체리는 당신이 원하는 것을 고르고 계속 움직입니다.

일부는 동의하지 않을 수 있지만 소스 코드없이 라이브러리 사용을 거부합니다.

라이브러리, 라이브러리의 용도, 코드에 얼마나 널리 퍼져 있는지, 업그레이드 수행 비용 (시간 및 비용) 등에 따라 다릅니다.

이상적으로 항상 항상 최신 버전을 사용하는 것이 좋지만 새 버전이 이전 버전과 호환되지 않으면 어떻게해야합니까? 변경 사항을주의 깊게 처리 할 수있을 때까지 향후 릴리스를 위해 해당 업데이트를 보류해야 할 수도 있습니다. 테스트에서 확인하기 어려운 동작에 약간의 변화 (예 : "메소드 Y를 호출하기 전에 속성 X를 설정해야하거나 메모리 누수가 느려진다")가있을 수 있습니다.

반면에 새 버전에는 심각한 보안 수정 사항이있을 수 있으므로이 사항도 고려해야합니다.

짧은 버전 : 사례별로 가져옵니다.

이것은 릴리스 셰들에 따라 다릅니다.

그러나 내 충고는 모든 개발자 컴퓨터에 라이브러리 세트를 설치하는 것입니다. 무언가를 부르고 싶다면 금본위 제로 생각하고, 그 릴리즈를위한 개발을 시작하십시오.

릴리스가 배포되고 릴리스 이후 단계 인 경우에만 라이브러리, 해당 버전 및 기능을 다시 평가하십시오. 이들이 중요한 개선 사항이나 새로운 기능을 제공한다면 다음 개발주기가 시작되기 전에 설치하십시오.

소프트웨어를 배포하기 전에 수정해야하는 주요 문제 또는 버그가있는 경우에만 새 버전을 설치하십시오.

그것은 당신이 어떤 버전을 놓칠 것이라는 것을 의미 할 것이지만, 당신은 당신의 어플리케이션 개발에 집중할 수있게하는 약간의 두통과 버저 닝 문제를 줄여야합니다.

서브 버전 외부

이 기능에서 좋은 점은 원하는 개정을 지정할 수 있다는 것입니다.

외부 장치가 많으면 업데이트 속도가 느려집니다.

나는 현재 다음과 같은 것을 설정하고있다 :

• 내 응용 프로그램의 각 확장마다 1 개의 수은 저장소
• 여러 타사 라이브러리의 특정 버전을 수집하는 수은 저장소
• 그래픽 리소스 / 작업을위한 SVN 저장소 (그러나 다른 것으로 변경 될 수 있음)
• 내 응용 프로그램의 수은 저장소, 수은 하위 저장소 기능을 사용하여 특정 버전의 3 차 저장소 및 일부 기본 확장을 사용합니다.

이제 "기본"이 아닌 확장 (내재적으로 응용 프로그램 저장소에 하위 저장소로 포함됨)이 아닌 확장에 대해 작업해야하는 경우 확장 폴더에서 저장소를 복제하여 CMake가 전체 응용 프로그램에 대한 프로젝트 및 솔루션을 생성하도록합니다.

그런 식으로 할 수 있습니다 :

• 클론에서 타사를 변경하고 앱과 작동하는지 확인하고 타사 Parpo 저장소에서 푸시 한 다음 응용 프로그램 저장소의 하위 저장소 버전을 새 타사 저장소 버전으로 업데이트하십시오.
• 확장 기능을 독립적으로 작업하거나 모든 togeter를 작업하거나
• 프로젝트를 서로 연결해야하는 것에 대해 걱정할 필요가 없습니다. 이는 전체 응용 프로그램 저장소로 프로젝트 하위 리포지토리를 검색하기 만하면 Cmake가 수행합니다.

아직이 조직에 대한 경험이 많지 않지만 매우 유용하다고 생각합니다.

소프트웨어가 보안에 중요한 경우 변명없이 가능한 빨리 업데이트해야합니다. 전체 프로그램을 취약하게 만들기 위해 그래픽 라이브러리에 약간의 버그가있는 것을 원하지 않습니다.

그렇지 않으면, lib가 성숙 할 때 "이것이 깨지지 않았다면 수정하지 마십시오." 나를 위해. 조만간, 나중 버전의 기능이 필요할 수 있으며 업데이트하는 것 외에는 선택의 여지가 없지만 그때까지는 노력을 정당화하기가 어렵습니다. 반면에 Grails 또는 ExtJS와 같이 비교적 새로운 라이브러리 또는 프레임 워크로 작업 할 때는 이러한 제품이 아직 완전히 성숙하지 않아 최신 버전으로 업데이트되므로 업데이트를 통해 나를 구할 수 있습니다. 이후 버전에서 수정 된 버그 중 하나에서 실행되지 않습니다.

NuGet 을 사용 하여 타사 라이브러리를 최신 상태로 유지합니다.

친구, 동료 또는 블로그에서 타사 DLL 중 하나가 오래되었다는 알림을 받으면 NuGet을 사용하여 업데이트하기가 매우 쉽습니다.