Я хотел бы развернуть скомпилированное программное обеспечение по всему миру.Subversion как развертывание программного обеспечения
Поскольку у меня уже был сервер subversion для управления версиями кода, я намерен использовать SVN для развертывания программного обеспечения. Однако, поскольку многие люди используют apt-get для развертывания программного обеспечения, я хотел бы увидеть плюсы и минусы использования SVN за apt-get.
Не проверяйте скомпилированный код в Subversion! Это особенно актуально для пакетов (RPM или .deb).
Что я видел, люди хранят свои пакеты в Subversion, а затем используют браузер Web-SVN для указания URL-адреса или делают checkout и помещают пакет в свою локальную систему. Я не рекомендую этого.
Причина проста: скомпилированный бинар занимает много места. Наши пакеты RPM могут составлять сотни мегабайт. Каждый раз, когда вы совершаете одно в Subversion, вы увеличиваете размер своего репозитория на несколько сотен мегабайт. После нескольких выпусков у вас есть гигабайт стоимостью двоичных файлов в вашем репозитории.
И для чего? Вы не можете diff двоичные файлы в Subversion. Вы не можете смотреть на их историю и видеть что-нибудь полезное. И, двоичные файлы имеют короткий срок хранения. Это особенно верно, когда принято выпускать несколько раз в месяц. Вы в конечном итоге с раздутым хранилищем, который должен поддерживаться, а 90% - информация, о которой никто не заботится.
Все же люди делают это, потому что это удобно. Вы даете кому-то URL Subversion, и они могут загрузить его. Большая сделка. Если у вас есть выделенный сервер выпуска, они могут сделать то же самое, и это будет быстрее. И вы можете удалить старые версии, которые больше никому не нужны, и экономить пространство на гигабайтах.
Просто потому, что многие люди делают что-то не значит, что вы тоже должны. Многие люди тоже делают героин, и я тоже этого не рекомендую.
У вас есть сервер сборки, например Jenkins? Если да, сохраните свои скомпилированные пакеты там. Вы можете удалить старые пакеты (Jenkins сделает это для вас) и сохранить соединение между исходным кодом и пакетом.
В одном месте, где я работал, мы устанавливаем Дженкинса с помощью Promoted Build Plugin. Когда мы выпустили релиз, мы отправились в сборник Jenkins, а продвинули. Продвижение помечает наш исходный код, блокирует сборку, чтобы не допустить, чтобы Дженкинс удалил архивный пакет и отправил пакет на наш сервер apt-get. Еще лучше, мы бы отметили сборку номером релиза. Вы можете пойти в Дженкинса, найти сборку, которая была выпущена, просмотреть исходный код, загрузить пакет и просмотреть все изменения между одной сборкой и следующей.
Наш репозиторий Subversion содержит только источник, и пользователи могут использовать фактический сервер пакетов apt-get для автоматического обновления пакетов.
Спасибо за подробную информацию. Мне кажется, что вопрос не похож на «банан лучше оранжевого, чем яблоко»? – Winston
SVN содержит источник, тогда как apt-get будет заботиться обо всех установках для продукта. Обычно при использовании SVN вы можете получить только копию программного обеспечения, и вам нужно будет установить его самостоятельно, вручную.
Надеюсь, это поможет.
Это похоже на вопрос: «Является ли банан лучше оранжевым, чем яблоко?» – thekbb
Я думаю, что люди должны использовать «apt-get» над SVN. И я хотел бы понять причину. Поэтому я ищу ответы от других разработчиков. – Winston
@Winston Можете ли вы объяснить, как вы собираетесь использовать SVN для развертывания? – ottodidakt