Java 개발자를 위한 DevOps 도구

6장. 패키지 관리

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

익쉘 루이즈

이 코드 줄은 궁극적으로 하나 이상의 엔터프라이즈 제품에서 조직 내부적으로 사용되거나 공용 리포지토리, 특히 Maven Central for Java 및 Kotlin 라이브러리를 통해 공유되는 빌딩 블록이 될 아티팩트의 일부가 될 것입니다.

오늘날에는 그 어느 때보다 많은 라이브러리, 바이너리 및 아티팩트를 사용할 수 있으며 전 세계 개발자가 차세대 제품과 서비스를 계속 개발함에 따라 이 컬렉션은 계속 증가할 것입니다. 이러한 아티팩트 를 처리하고 관리하려면 종속성이 계속 증가하여 복잡한 연결망으로 인해 이전보다 더 많은 노력이 필요합니다. 잘못된 버전의 아티팩트를 사용하면 쉽게 함정에 빠져 혼란을 초래하고 빌드가 손상되어 결국 신중하게 계획된 프로젝트 출시 일정에 차질을 빚을 수 있습니다.

개발자가 눈앞에 있는 소스 코드의 기능과 특성뿐만 아니라 프로젝트가 패키징되는 방식과 빌딩 블록이 최종 제품으로 조립되는 방식을 이해하는 것이 그 어느 때보다 중요합니다. 빌드 프로세스 자체와 자동화된 빌드 도구의 내부 작동 방식을 깊이 이해하는 것은 불필요한 문제 해결로 인한 지연과 시간을 방지하는 것은 물론 대규모 버그가 프로덕션으로 유출되는 것을 방지하는 데에도 매우 중요합니다.

일반적인 코딩 문제에 대한 해결책을 제공하는 수많은 타사 리소스에 액세스하면 프로젝트 개발 속도를 높이는 데 도움이 될 수 있지만 오류나 예기치 않은 동작이 발생할 위험이 있습니다. 이러한 구성 요소가 프로젝트에 도입되는 방식과 그 출처를 이해하면 문제 해결에 도움이 될 수 있습니다. 내부에서 생성되는 아티팩트를 책임감 있게 관리하면 버그 수정 및 기능 개발과 관련하여 의사 결정과 우선 순위를 개선할 수 있을 뿐만 아니라 프로덕션에 릴리스하는 데 도움이 됩니다. 개발자는 더 이상 눈앞에 있는 코드의 의미뿐만 아니라 패키지 관리의 복잡성에도 정통할 수 없게 됩니다.

빌드-잇-앤-쉽-잇만으로는 충분하지 않은 이유

얼마 전까지만 해도 소프트웨어 개발자들은 아티팩트를 구축하는 것을 힘들고 때로는 엄청난 노력의 정점으로 여겼습니다. 마감일을 맞추기 위해 지름길과 제대로 문서화되지 않은 단계를 사용하기도 했습니다. 그 이후로 업계의 요구 사항은 더 빠른 배포 주기, 다양한 환경, 맞춤형 아티팩트, 폭발적인 코드베이스 및 저장소, 다중 모듈 패키지로 변화했습니다. 오늘날 아티팩트 구축은 큰 비즈니스 사이클의 한 단계에 불과합니다.

성공적인 리더는 최고의 혁신은 시행착오에서 나온다는 사실을 잘 알고 있습니다.그렇기 때문에 그들은 테스트, 실험, 실패를 자신의 삶과 회사 프로세스의 필수적인 부분으로 삼고 있습니다.

혁신, 더 빠른 확장, 더 많은 제품 출시, 애플리케이션이나 제품의 품질 또는 사용자 경험 개선, 새로운 기능 출시를 위한 한 가지 방법은 A/B 테스트를 이용하는 것입니다. A/B 테스트란 무엇인가요? ...