Давайте посмотрим, смогу ли я сломать это для вас.
В настоящее время мы храним библиотеки и сторонние инструменты, которые нам нужны во время нашей сборки, в нашем хранилище кода. Мы хотели бы проанализировать другие способы хранения и доступа к сторонним инструментам и библиотекам.
- Будет ли Artifactory подходящим инструментом для их хранения?
Да, Artifactory и другие серверы репозитория пакетов обычно имеют бинарный / необработанный репозиторий, который был бы хорошим вариантом. Думайте об Артефакторе как о месте, где вы можете использовать свои артефакты. Таким образом, эти библиотеки, сторонние инструменты, стороннее программное обеспечение, модули и т. Д. Могут храниться в различных типах репозиториев в Artifactory. Artifactory будет менеджером репозитория пакетов уровня предприятия, оптимизированным для этого, обработки High Available и многого другого. Здесь вы храните, защищаете и внедряете двоичные файлы, пакеты, программное обеспечение и т. Д. Это может быть в средах Dev, Test, Stage и Production.
- Насколько я понимаю, Artifactory должен использоваться только для хранения артефактов сборки, которые могут быть выброшены и воссозданы.
Я думаю, что это немного не так - это близко. Вы могли бы хранить артефакты сборки, которые можно было бы выбросить и воссоздать, но вы также можете хранить гораздо больше. Заявление об этом таким образом на самом деле не дает должного понимания тому, что он может на самом деле делать.
- ИЛИ лучше ли использовать Chocolatey?
Это не конкурентный вариант для Артефактуры. Шоколадные пакеты можно хранить в Artifactory (Pro) в хранилище типов NuGet. Двоичные файлы будут либо IN пакетов Chocolatey, либо могут находиться в двоичном / необработанном хранилище.
Artifactory - это хранилище пакетов, где Chocolatey - менеджер пакетов (управление программным обеспечением и развертывание) для Windows.
Насколько я понимаю, нам нужно будет создавать пакеты Chocolatey из наших сторонних инструментов и библиотек. Где же:
источник этих пакетов, например (.exe, .dll, .zip, .msi) обычно проживают?
- В расположении файла UNC?
- Или в бинарном хранилище, таком как Artifactory?
- Является ли использование бинарного хранилища для хранения зависимостей времени сборки правильным подходом?
Вы забыли наиболее часто используемый и рекомендуемый подход:
В самой упаковке Chocolatey самое рекомендуемое место для хранения двоичных файлов, которые представляет пакет. Это самый детерминированный и надежный метод для пакетов.
Проблема в том, что вы можете рассматривать хранилище пакетов сообщества в качестве примера упаковки - мы рекомендуем НЕ делать этого, так как он не представляет, но, возможно, 5% пакетов там. Мы не рекомендуем придерживаться этого подхода, поскольку он не является надежным.
- Он должен постоянно находиться там, и каждая новая версия будет добавлять к размеру хранилища.
Это правда, однако в Artifactory есть подход отбраковки (я полагаю), и он оптимизирован для этих типов сценариев. Мы просматриваем рекомендации по системным требованиям для различных коммерческих решений для хранилищ по адресу https://chocolatey.org/docs/how-to-host-feed#commercial-repository-system-requirements.
- Шоколадные пакеты сами проживают?
- В расположении файла UNC?
Они абсолютно могут, но имейте в виду, как разрешения работают с общими файлами и разрешениями Windows - https://chocolatey.org/docs/how-to-host-feed#local-folder-permissions
- Или в бинарном хранилище, таком как Artifactory?
Нет, это будет репозиторий NuGet OData, доступный в Artifactory Pro. Да, репозиторий NuGet Artifactory был бы отличным местом, и можно было бы использовать несколько репозиториев для разных сред, разрешений и т. Д. Что бы ни имело смысл для вашей среды.
- Является ли использование бинарного хранилища для хранения зависимостей времени сборки правильным подходом? Он должен постоянно находиться там, и каждая новая версия будет добавляться к размеру хранилища.
Я думаю, что это было обработано в другом месте.
- Если мы храним сторонние инструменты и библиотеки вне нашего репозитория кода
- Нужно ли нам использовать Chef и Chocolatey для доступа к ним?
- ИЛИ мы можем получить к ним доступ напрямую из TFS, используя Chocolatey, не используя Chef в процессе сборки?
Вы можете сделать как обычно. Если вы добавите сторонние инструменты в пакеты для развертывания программного обеспечения (например, пакеты Chocolatey), вам понадобится Chocolatey для управления развертыванием.
- Правильно ли я считаю, что Chef в первую очередь используется для настройки сред сборки с необходимым программным обеспечением и переменными среды перед началом процесса сборки?
Я бы сказал, что вы неправильно понимаете Chef - это решение для управления конфигурацией. Он может настраивать среды сборки и поддерживать их в требуемом состоянии, но это ограничивает возможности. Chef (и другие менеджеры конфигурации) используются для составления сценария состояния ожиданий (желаемого состояния) для вашей инфраструктуры (инфраструктура в виде кода), которую вы можете проверить в системе контроля версий и протестировать изменения всей инфраструктуры перед развертыванием, возможно, с помощью непрерывной интеграции (CI). ) такие серверы, как Jenkins, TeamCity, TFS (что приводит к тестированию вашей инфраструктуры, тестированию инфраструктуры и т. д.) и т. д. Для разработчиков это несколько интуитивно понятно, но для людей, работающих на стороне предприятия, это все новее. довести эти методы разработки до операций. Я называю это современной автоматизацией, но некоторые люди называют такие смены DevOps.
Рекомендация
Вы можете использовать решение Chef + Chocolatey + Artifactory для управления программными и машинными конфигурациями в вашей организации, а не только в средах разработки. Я думаю, возможно, что вы подходите ко всем этим инструментам с точки зрения позиции типа разработчика и, таким образом, просто думаете в контексте предоставления, а не долгосрочного управления развертываниями, конфигурацией и т. Д., Что может быть операционным / системным администратором. смотря на. Все эти инструменты, безусловно, добавляют что-то новое, но все они бесплатные и совсем не конкурирующие решения. Для многих крупных организаций размещение этих или аналогичных компонентов создает архитектуру, которая может удовлетворить критически важные потребности инфраструктуры современных организаций.