" 아티팩트 저장소 란 무엇입니까? "에 대한 질문 에는 저장소 부분에 대한 흥미로운 설명 이 들어 있습니다. 그리고 전체 답변을 읽음으로써 DevOps의 맥락에서 정확히 " 아티팩트 "가 무엇을 의미 하는지 잘 모르겠습니다 .
어떤 제안?
추신 : 대답 중 하나에서 아마도 인공물 이 내가 궁금해하는 것 (혼란?) 이라는 것을 이해하는 것 같습니다 ...
답변:
Wikipedia에는이 질문에 대한 답이 아주 좋습니다. 파생 객체 라고도하는 아티팩트 는 코드 리포지토리에 적용된 일부 프로세스 의 제품입니다 . 원래 그것들은 Build Artifacts 라고 불렸지만 , 그것들을 만들기 위해 빌드 이외의 프로세스가 더 많이 적용됨에 따라 첫 단어는 간단하게 삭제되었습니다.
주요 차이점은 동일한 프로세스를 사용하여 코드 저장소에서 아티팩트를 재 작성할 수 있다는 것입니다. 프로세스가 적용된 환경을 보존 한 경우입니다. 이 프로세스는 시간이 많이 걸리고 환경을 완벽하게 보존하여 아티팩트를 똑같은 방식으로 다시 만들 수 있으므로 아티팩트 리포지토리 에 저장하기 시작했습니다 .
아티팩트 리포지토리 에서 코드 리포지토리 와 별도로 저장하는 것은 DevOps 엔지니어가 결정할 디자인 결정입니다. 일부 기업, 즉 퍼포 , 제안 뿐만 아니라 유물 저장소로 자신의 코드 저장소를 사용합니다. 각 저장소 의 액세스 , 감사 , 객체 크기 , 객체 태그 지정 및 확장 성 측면에서 서로 다른 요구 사항이 있으므로 상황에 따라 두 가지 다른 제품을 사용하는 것이 더 좋습니다. 예를 들어 Git리포지토리는 전체 개발 시스템에 전체적으로 복사되므로 코드 리포지토리에 아티팩트를 저장하면 최근에이를 완화 할 수있는 방법이 있지만 모든 이유를 넘어서서 크기가 증가합니다. 또 다른 결정은 저장할 아티팩트입니다. 일부 회사는 중간 아티팩트를 개별 오브젝트 파일로 저장하여 재 구축 속도를 높이고 다른 회사는 단순히 최종 바이너리 만 저장합니다. 모든 아티팩트가 동일한 값을 갖는 것은 아닙니다. 릴리스 빌드로 인한 아티팩트는 개발자 빌드로 인한 아티팩트와 다른 요구 사항을 가질 수 있습니다.
가장 일반적인 아티팩트는 구성 , 전처리 , 컴파일 , 링크 , 자동화 된 테스트 , 아카이빙 , 패키징 , 미디어 파일 생성 및 처리 , 데이터 파일 생성 , 문서 파싱 , 코드 분석 , QA 등의 프로세스 결과입니다 .
"아티팩트"라는 단어의 두 가지 사용법이 있으며 하나는 소스 코드를 아티팩트로 만드는 반면 두 번째는 아티팩트가 아닌 것으로 만듭니다. 실제로 이것은 매우 혼란 스러울 수 있습니다!
구체적인 것, 이상적인 것으로서의“인공물” –이 의미는“사람이 만든 물건, 일반적으로 문화적 또는 역사적 관심사 중 하나”라는 단어의 일반적인 의미이며 기술적 전문 용어가 아닙니다. 다음은 기술적 인 맥락의 예입니다 . 소프트웨어를 디버깅 할 때 소프트웨어에 대해 알아 봅니다. 이 학습을 회귀 테스트와 같은 소프트웨어 아티팩트로 전환하는 것은 종종 귀중한 투자입니다. 그렇지 않으면이 학습은 잊혀지고 학습을위한 노력은 낭비 될 것입니다. 이러한 의미에서 소스 코드는 인공물로 간주됩니다.
레시피에 의해 생성 된 것으로서 "아티팩트" –이 의미는 일부 난해한 레시피를 사용하여 연금술사의 대중적인 이미지를 사용하여 종종 아티팩트라고하는 마법 장치를 생성합니다. 연금술사의 은유의 레시피에 해당하는 소스 코드와 연금술사의 은유의 인공물에 해당하는 해당 소스 코드에서 파생 된 것을 구별하는 데 사용되는 전문 용어입니다. 예를 들어 plop-fizz 프로그램의 인공물 제작을 자동화했습니다. 이제 소스 tarball, 서명 파일, DEB 및 RPM 패키지를 모두 하나의 명령으로 인스턴스화 할 수 있습니다! 이 의미는 소스 코드에서 생성 된 용어를 나타내는 데 사용되는 용어이므로 소스 코드를 인공물로 인식하지 않습니다.
답은 장소마다 다를 수 있다고 생각합니다. 현재 내가 일하는 곳에서 아티팩트는 개발에 사용되는 소스 코드를 제외하고 다른 엔티티가 소비하는 것입니다. 이것은 소스 제어에 들어갑니다.
여기에는 제품 바이너리 또는 기타 필요한 제품, 라이브러리, 객체 파일, 미디어 파일 또는 테스트 데이터와 같은 테스트 아티팩트가 포함됩니다.
소스 코드는 아티팩트로 간주되지 않습니다. "소비자"의 정의와 일치하지 않는 한, 타사 라이브러리, 테스트에 사용되는 스크립트 코드 또는 기타 목적 (개발 버전 자체는 아님)을 포함합니다.
문화 측면에 대한 참고 사항. DevOps에서는 "아티팩트 저장소"라는 개념을 주어진 상황으로 간주하지만 조직 프로세스와 관련이없는 것 같습니다.
문화 문제 : 조직에서 ITIL을 사용하는 경우 인증 된 직원은 "우리가 생산 한 소프트웨어 구성 항목을 배치하기위한 저장소와 같은 명확한 미디어 라이브러리가 필요합니다"라고 말합니다. 따라서 체계적으로 구성된 IT 프로세스에 관심이있는 사람들은이를 지원하고 사용중인 (관리되지 않는) 도구를 모릅니다. 반대로, Nexus 또는 Artifactory 언어에 대한 타당성이 필요한 경우 조직에 따라 설명하기가 어려울 수 있습니다.
추가 자료 : https://en.wikipedia.org/wiki/Definitive_Media_Library