작업 개발 환경에서 과거 프로젝트를 효과적으로 유지하는 방법은 무엇입니까?

과거 프로젝트를 실행하려고 할 때마다 프로젝트를 찾을 수 있고 프로젝트를 실행할 수 있도록 모든 것이 다시 설정되기까지 시간이 오래 걸린다는 것을 알았습니다.

예를 들어, Linux에서 만든 python 프로젝트가 있으며 Linux에 쉽게 설치되는 소프트웨어 패키지에 의존하지만 더 이상 사용중인 Linux VM이 없습니다. 그리고 내 다른 프로젝트 중 일부는 웹 서버 구성, PATH 변수, SDK, IDE, OS 버전, 장치 등과 같은 다른 변수에 의존합니다.

누군가이 문제를 효과적으로 처리 할 수 ​​있습니까? 현재로서는 소스 코드를 백업하는 데 관심이 있지만 작업 개발 환경을 다시 설정하는 것은 어렵고 작업 개발 환경을 유지하는 것도 어렵습니다 .

과거에 한 것은 실제 개발 시스템을 VM으로 변환하거나 이미 VM 인 경우 나중에 사용할 수 있도록 보존하는 것입니다. 디스크 공간 사용량만큼 효율적이지 않지만 공간이 저렴합니다. 또한이 프로세스는 필요할 때 나중에 환경을 재구성하려고 시도하는 것보다 시간이 훨씬 덜 소요됩니다.

내가 가장 좋아하는 방법은 프로젝트에 필요한 모든 종속성을 설치하고 소스를 다운로드하며 모든 것을 연결하는 스크립트를 유지 관리하는 것입니다. 일부 스크립트에는 두 가지 모드가 있습니다. 하나는 프로덕션 모드이며 다른 모드의 일부인 개발입니다.

일부 환경은 스크립트로 설치하는 데 약 5 분이 걸립니다.이 경우 아침에 직장에 도착하면 프로젝트 스크립트를 배포 할 대상 OS를 새로 설치하여 로컬 VM을 유지 한 다음 모든 코딩을 수행합니다. 해당 VM 인스턴스에 대한 관련 작업. 나가기 전에 git을 통해 모든 변경 사항을 실제 컴퓨터 또는 중앙 저장소로 푸시하고 VM을 종료합니다.

환경을 설치하는 데 시간이 오래 걸리는 경우 (장기 설치, 큰 파일 다운로드 등) 일주일에 한 번 위의 절차를 수행합니다.

새로운 시스템 및 / 또는 프로덕션 서버에 배포하기가 매우 쉽고 스크립트에 모두 문서화되어 있으며 스크립트가 자주 확인된다는 이점이 있습니다.

설명하는 개념은 구성 관리입니다. 이는 환경을 식별, 기록, 버전 / 추적 및보고하는 방법입니다. 버전 관리 및 빌드 관리와 밀접한 관련이있는 작업이지만, 동일한 개념과 동일한 처리 및 저장 메커니즘을 사용하더라도 별도의 전략이 필요한 경우가 많습니다.

작업 환경을 통제 할 수 있도록하는 것 외에 구성 관리는 소프트웨어가 사용되는 다양한 작업 환경 (설명 된대로 개발, 테스트 / QA, 일상적인 고객에 대한 배포, 특별한 고려 또는 특별한 구성이 필요한 고객에 대한 배포)에 대한 기록을 수립하는 데 도움이됩니다. 또는 속성 등을 빌드 할 수 있습니다.

내가 말했듯이, 이것은 종종 소스 버전 제어와 일치하는 작업이며 종종 구성 관리 데이터는 문서와 소스 저장소 모두에서 소스 옆에 있습니다. 반드시 그럴 필요는 없지만 종종 편의상의 문제입니다.

최근 몇 년 동안 구성 관리의 일부 측면의 자동화가 크게 개선되었습니다. 일부 답변과 의견은 구성 관리를 촉진하기위한 방법으로 스크립트를 제안했으며, 스크립트는 재현 가능한 결과를 얻는 데 도움이되는 좋은 대답이지만 종종 수작업으로 작성된 스크립트 자체가 일관성이없고 불완전합니다. 이러한 개선 된 방법 중 하나는 자동 프로비저닝을 사용하는 것입니다. 꼭두각시 또는 요리사 와 같은 시스템특정 사용자 또는 시스템 또는 특정 작업 프로필에 대한 소프트웨어 구성 요소 및 시스템을 지정하고 완전한 시스템 또는 환경을 설정하는 데 도움이되는 '레시피'를 제공합니다. 기본적으로 소프트웨어 배포 저장소의 개념을 취하여 시스템에 필요한 소프트웨어 패키지뿐만 아니라 각 패키지에 특정한 구성 프로파일을 제공하여이를 확장하고 일반화하여 사용자에게 적합한 방식으로 사용할 수 있도록합니다. 상태.

Vagrant 는이를 약간 다른 방향으로 가져 와서 가상 머신 정의를 신속하게 스핀하는 방법을 제공하여 VM이 가상 소프트웨어 및 하드웨어를 자동으로 프로비저닝 할 수 있고 특정 하드웨어 표현을 재현 할 수있는 편리한 방법이 될 수 있습니다 소프트웨어 사용자가 사용하는 환경.

각 시스템 (및 변형)은 설정하는 데 약간의 시간이 걸리지 만 다시로드하고 재구성하는 작업이 일반적인 작업 인 경우 분명한 가치가 있습니다.

Docker 는 좋은 옵션입니다. dockerfile을 사용하여 원하는 VM의 매니페스트로 작동 할 수 있습니다. 이미지를 저장할 필요가 없으며 필요한 이미지를 다운로드합니다. 또한 자체 이미지를 사용할 수 있으므로 자체 기본 이미지를 만든 다음 환경에 필요한 구성 요소를 추가 할 수 있습니다.

도커를 사용하면 워크 플로의 다른 부분도 향상시킬 수 있습니다.

• 생성 된 환경은 프로젝트와 동일한 CVS에 배치 할 수있어 버전이 지정된 환경을 제공합니다 (정말!)
• 도커를 사용하면 실제 환경을 프로비저닝하여 프로젝트에서 프로젝트를 시작하는 데 따르는 어려움을 줄일 수 있습니다.
• 다른 사람들이 당신과 함께 일하기 시작하면, 그 거대한 환경 설정을로드하기 위해 dockerfile 만 있으면됩니다.

따라서 VM 사용에 대한 아이디어는 부분적으로 옳습니다. HDD가 점점 커지고 있음을 알고 있지만 모든 공간을 다 쓸 필요는 없습니다. 또한 VM 환경에 내부적으로 더 많은 HDD 공간이 필요한 경우 약간 까다로울 수 있으며 다시 만들어야 할 수도 있습니다. 파일 크기는 문제가되지 않지만 일반적인 DSL 연결에서 5Go를 통해 전송해야 할 경우 인터넷 속도가 여전히 병목 현상이됩니다.

대부분의 시스템 (언어, 런타임 또는 운영 체제)에는 소프트웨어 및 구성을 설치하는 표준화 된 방법이 있으므로 사용하십시오. 같은 :

• Java 용 Maven 또는 Gradle
• Perl 용 CPAN
• RedHat / Fedora의 경우 rpm
• Linux 용 dpkg / apt-get
• Windows 용 MSI 패키지

그런 다음 정확히 설치해야하는 단계와 필요한 단계를 설명하는 설치 지침을 작성하십시오.

• 설치 대상에 대한 간단한 지침을 제공하십시오 (기본 OS, Java / Perl / Python 등의 기본 런타임).
• 필요한 설치를 수행하는 짧은 스크립트 작성 (이상적으로는 Maven과 같은 도구를 한 번만 호출)
• 새로 설치 (예 : VM)에서이를 테스트하십시오.

그런 다음 환경을 재현 할 수 있어야하며 다른 환경 도 그렇게 할 수 있어야합니다 (솔로 프로젝트가 아닌 경우 중요 할 수 있음).

필요한 설치 패키지를 어딘가에 저장하거나 다운로드 지침을 포함시킬 수 있습니다 (시스템이 apt-get 또는 Maven과 같은 것을 추적하지 않는 한). 패키지 제공 업체를 얼마나 신뢰하는지에 달려 있습니다. 핵심 데비안 패키지를 저장할 필요는 없지만 소규모의 무료 소프트웨어 프로젝트를 사용하는 것이 좋습니다.

VM 솔루션도 작동하며 단기적으로는 작업량이 적을 수 있습니다 (VM 만 유지). 그러나이 솔루션은 환경을 변경할 때와 같이 더 많은 유연성을 제공한다고 생각합니다.