최근에 NetApp은 개발 프로세스의 일부로 자체 서비스와 어플라이언스를 사용한다고 밝혔습니다. 이를 "자신의 개 사료 먹기"라고도 합니다. 내부적으로 도구를 사용하는 방법에 대한 그들의 이야기는 NetApp 채택을 고려하는 모든 사람에게 흥미로운 사례 연구를 제공합니다. 작년에 그들은 새로운 릴리스와 업데이트의 원동력이었습니다. 한 가지 예로서, 그들은 올플래시, 종단간 NVMe 서버 랙을 출시했습니다. 넷앱 AFA EF600, 바로 지난달.
최근에 NetApp은 개발 프로세스의 일부로 자체 서비스와 어플라이언스를 사용한다고 밝혔습니다. 이를 "자신의 개 사료 먹기"라고도 합니다. 내부적으로 도구를 사용하는 방법에 대한 그들의 이야기는 NetApp 채택을 고려하는 모든 사람에게 흥미로운 사례 연구를 제공합니다. 작년에 그들은 새로운 릴리스와 업데이트의 원동력이었습니다. 한 가지 예로서, 그들은 올플래시, 종단간 NVMe 서버 랙을 출시했습니다. 넷앱 AFA EF600, 바로 지난달.
NetApp의 SolidFire 및 하이퍼 컨버지드 인프라(HCI) 엔지니어링 팀 모두 NetApp HCI 어플라이언스와 소프트웨어를 개발 파이프라인의 일부로 사용합니다. 팀은 Jenkins를 사용하여 CI(지속적인 통합) 및 배포 빌드를 생성합니다. 그런 다음 이러한 빌드는 하이브리드 클라우드 제어 제품군이 활성화된 NetApp HCI 어플라이언스에서 실행되는 NKS(NetApp Kubernetes Service)를 통해 배포됩니다. NKS를 사용하면 엔지니어링 팀이 Amazon EC2, Google Cloud Platform(GCP) 또는 Azure와 같이 현재 요구 사항에 가장 적합한 퍼블릭 클라우드로 빌드를 푸시할 수 있습니다. 더 자주 팀은 Istio 서비스 메시를 사용하여 여러 클라우드에 빌드를 배포하여 한 번에 여러 대상에 대한 테스트를 허용하는 하이브리드 다중 클라우드 애플리케이션을 제공합니다. NetApp은 이 프로세스를 통해 내부 사용을 위한 새로운 CI/CD(지속적인 통합 및 지속적인 배포) 파이프라인을 최대 XNUMX배까지 단축할 수 있었다고 주장합니다. 이것은 정말 엄청난 시간 절약이며, 그들이 이 주장을 공개적으로 기반으로 하고 있는 수치를 만들었으면 합니다.
NetApp은 데이터 패브릭 아키텍처에 공급되는 빌드 파이프라인을 개발하기 위해 여전히 몇 가지 선행 작업을 수행해야 하지만 (CI/CD) 파이프라인을 직접 설정하는 데 몇 주를 소비했음을 인정합니다. 이 과정은 매우 매력적입니다. 더욱이 일단 설정되면 이러한 방식으로 빌드를 퍼블릭 클라우드로 푸시하면 솔루션이 확장되어 거의 모든 팀 규모를 처리할 수 있습니다.
