...
...
artifact, Package, Library, Component
언어나 프레임워크마다 package, library, component 를 비슷한 의미로 사용하는 경우가 많으며 일반적으로는 라이브러리라고 이해하면 됩니다.
아티팩트는 소프트웨어 개발 프로젝트를 진행하면서 생성하는 다양한 산출물을 의미하며 각종 설계 문서, 유즈 케이스, UML 다이어그램, 소스 코드, 소스를 빌드하여 생성된 라이브러리나 실행 파일도 모두 아티팩트에 속합니다.
...
패키지 관리자를 제공하는 언어들은 각자의 중앙 저장소(Central Repository)가 있으며 자바의 경우 https://repo1.maven.org/maven2, 파이썬의 경우 https://pypi.python.org, PHP 의 경우 http://packagist.org/ 등의 저장소가 있습니다.
이외에도 상용 라이브러리이거나 내부에서 개발한 라이브러리를 사내의 다른 개발자나 프로젝트와 공유하기 위한 배포 용도로 사용하는 사설 저장소(Private Repository)도 있습니다.
저장소 관리자(Repository Manager)
저장소 관리자는 저장소의 기능을 제공하고 관리자 기능을 제공하는 소프트웨어를 의미하며 라이브러리를 등록/삭제/배포하고 컴포넌트의 생명주기를 관리하기 위한 용도로 사용됩니다.
특히 사설 저
Private Repository 회사나 개발팀에서
추가로 중요한 기능중 하나는 중앙 저장소를 미러링(Mirroring) 및 캐싱하여 빠른 속도로 빌드를 하게 해주며 중앙 저장소가 장애가 있어도 빌드 업무가 중단되지 않게 합니다.
주요 제품으로는 아파치 재단의 아카이바(archiva), JFrog 사의 아티팩토리(Artifactory), 소나타입사의 넥서스(nexus) 가 있다.
이 책에서는 가장 많이 사용하는 넥서스 저장소 관리자에 대해서 다룰 것이다.
이런 방식을 사용할 경우 다음과 같은 문제점들이 발생했다.
- 많은 용량 차지 - 아파치 재단의 라이브러리나 스프링 프레임워크등 공통적으로 사용되는 라이브러리들이 많이 있어도 프로젝트마다 버전 관리에 추가하여 사용하여 많은 용량이 필요하다.
특히 프로젝트 소스를 분기할 경우 라이브러리를 복사해야 하므로 분기 속도도 느려 진다. - 느린 빌드 빌드 - 버전 관리 용량이 크다보니 빌드를 위해 체크 아웃 받을 경우 시간이 더 걸리고 빌드도 느려지게 된다.
- 프로젝트 라이브러리 버전 관리 어려움 - 사용하던 라이브러리를 다른 버전으로 변경한다고 가정해 보자. 새로운 라이브러리를 구한 후에 버전 관리에 커밋해야 한다.
만약 새로운 라이브러리가 문제가 있어서 예전 버전으로 돌아가야 할 경우 버전 관리에서 삭제하고 커밋을 거쳐야 하는등 프로젝트에서 사용하는 라이브러리의 버전 관리가 어렵다. - 의존성 관리가 어려움 - 사용하는 라이브러리가 다른 라이브러리를 참고할 경우 개발자가 의존성을 알아서 파악해서 의존성 있는 라이브러리를 추가해 주어야 한다.
특히 버전이 갱신되어 의존성이 변경되거나 신규로 추가된 라이브러리일 경우 의존성 관리는 매우 번거로운 작업이다.
...
저장소는 위와 같은 문제점을 해결하기 위해 사용하며 다음과 같은 장점이 있다.
- 적은 용량 사용 - 저장소는 라이브러리를 보관하므로 프로젝트마다 필요한 라이브러리를 버전 관리에 추가할 필요가 없고 라이브러리에 대한 메타 데이타만 설정하면 빌드할 때 다운로드 받으므로 적은 용량을 사용한다.
- 빠른 프로젝트 체크아웃과 빌드 - 버전 관리 툴을 사용하여 프로젝트를 체크 아웃 받을 경우 용량이 적으므로 빨리 체크아웃 받을 수 있으며 빌드도 빨리 수행 가능하다.
- 라이브러리 버전 관리 용이 - 메타 데이타를 기반으로 라이브러리의 정보와 버전을 관리하므로 라이브러리 자체의 버전을 관리하기가 용이하다.
- 공유 및 협업 강화 - 저장소를 통해 컴포넌트를 공유할수 있으므로 개발자들끼리 손쉽게 산출물을 공유하고 협업할 수 있다.
저장소를 제대로 사용하기 위해서는 저장소를 지원하는 빌드 툴을 사용해야 한다.
메이븐(maven)이나 아이비(ivy) 등의 빌드 툴은 메타 데이타를 기반으로 저장소에서 라이브러리를 검색하고 다운로드 받는다.
저장소의 주소가 명시되지 않을 경우 메이븐 중앙 저장소에 연결하게 되며 이 저장소는 외국에 위치하고 있어서 속도가 느리므로 저장소를 사용해도 빌드가 느린 원인이 된다.
또 JDBC나 기타 라이브러리는 메이븐 중앙 저장소와 별도의 저장소를 제공하는 경우가 있으므로 따로 저장소를 지정하지 않으면 빌드가 실패하는 원인이 되기도 한다.
저장소 구조
저장소에 추가된 아티팩트는 디렉터리나 자바의 패키지처럼 계층적인 구조로 접근할 수 있다. 이 계층적 구조를 GAV(Group, Artifact, Version) 구조라고 하며 메이븐에서 의존성을 찾을 때 참고하는 구조이기도 하다.
Group Identifier(groupId)
그룹 ID는 아티팩트를 논리적인 그룹으로 묶기 위한 단위이다. 보통 개발하는 회사나 기관명뒤에 만드는 소프트웨어 컴포넌트명을 붙여서 짓는다. 예로 아파치 재단 산하의 메이븐 프로젝트의 그룹 ID 는 org.apache.maven 이다.
Artifact Identifier(artifactId)
아티팩트 ID 는 프로젝트의 결과물인 어플리케이션이나 라이브러리의 이름을 위미한다. 만약 개발하고 있는 프로젝트가 "example webapp" 라면 아티팩트 ID는 example-webapp 로 짓는다. 그룹 ID와 아티팩트 ID 를 합친 문자열은 유일한 식별자이어야 하며 다른 프로젝트일 경우 아티팩트 ID 를 달리해야 한다.
Version(version)
버전은 아티팩트의 버전이며 일반적으로 메이저, 마이너, 포인트로 나눠서 짓는다. example-webapp 의 메이저 버전이 1 이고 마이너가 2, 포인트 버전이 4일 경우 최종 버전은 1.2.4 가 된다. 버전에는 구분을 용이하게 하기 위해 문자열을 사용할 수 있다. 다음과 같은 버전도 유효한 버전명이다.
1.2.4-BETA3
2.0.0-RC5
Packaging(packaging)
메이븐을 빌드 도구로 사용할 경우 기본 패키지 형식은 JAR 파일이지만 저장소에 아티팩트 등록시 명시적으로 패키지 형식을 알려주어야 한다. 사용 가능한 패키지 형식은 JAR, ZIP, WAR, WAR, SWC 등이다.
릴리스와 스냅샷 저장소(Release and Snapshot Repositories)
프로젝트에서 공통으로 사용되는 라이브러리를 개발하는 별도의 프로젝트가 있다고 가정해 보자.
개발 단계의 라이브러리는 수시로 변경되며 자주 테스트 되어야 하지만 안정화 될 때까지는 이 라이브러리를 참조하는 프로젝트에서는 사용하지 않는게 좋을 경우가 많다.
이를 위해 안정 버전의 라이브러리와 개발 단계 라이브러리를 구분하여 저장소를 나누어 관리하면 유용할 것이다.
이를 위해 개발 단계에서는 스냅샷 저장소를 통해 배포하고 테스트가 끝나고 안정화된 라이브러리는 릴리스 저장소에 저장하여 배포한다.
보통 스냅샷 아티팩트는 구분을 위해 my-artifact-1.2.3-20140506.162341-1.jar 처럼 타입스탬프가 파일명에 추가된다.
저장소 관리자(Repository Manager)
저장소 관리자는 저장소의 기능 및 관리자 기능을 제공하는 소프트웨어를 의미하며 아티팩트를 저장/관리하고 컴포넌트의 생명주기를 관리하기 위한 용도로 사용된다.
주요 제품으로는 아파치 재단의 아카이바(archiva), JFrog 사의 아티팩토리(Artifactory), 소나타입사의 넥서스(nexus) 가 있다.
...
- .
...