С некоторыми сотоварищами развернулась интересная дискуссия. Как известно для того, чтобы собрать и задеплоить свой продукт на жабе требуется N-ное количество сторонних пакетиков в виде JAR-файлов.
Так вот, я доказываю, что для коммерческого продукта необходимо иметь полный и замкнутый цикл разработки, который включает в себя полное дерево исходников и пересборку 3rd-party jar-файлов, любое обращение к сети во время сборки должно быть запрещено.
Противоположная точка зрения -- все выкачивается из интернета в виде бинарных jar-файликов (в идеале при каждой сборке, как вариант -- кашируется 1 раз для локального использования).
Как по вашему -- кто прав и почему? ;-)
Так вот, я доказываю, что для коммерческого продукта необходимо иметь полный и замкнутый цикл разработки, который включает в себя полное дерево исходников и пересборку 3rd-party jar-файлов, любое обращение к сети во время сборки должно быть запрещено.
Противоположная точка зрения -- все выкачивается из интернета в виде бинарных jar-файликов (в идеале при каждой сборке, как вариант -- кашируется 1 раз для локального использования).
Как по вашему -- кто прав и почему? ;-)
no subject
Date: 2012-08-06 16:55 (UTC)no subject
Date: 2012-08-06 17:07 (UTC)Уже сколько раз обжигались:
- автор библиотеки сошел сума/вши захватили датцентр/молния ударила прямо в сервер.
И мы потеряли линк на библиотеку. Да, их будет еще много, форки там итд. Но это не вариант.
- у кастомера на объекте может не быть доступа к интернету(Служба Безопасности выдает интернет по талонам в большие православные праздники)
Кто работал с кровавыми энтерпрайзами знают как это бывает.
- C вероятностью 99.9% сторонние либы надо будет патчить. И лучше держать у себя их вместе со своими накатанными патчами.
no subject
Date: 2012-08-06 17:18 (UTC)no subject
Date: 2012-08-06 17:28 (UTC)no subject
Date: 2012-08-06 17:29 (UTC)no subject
Date: 2012-08-06 17:31 (UTC)[ С точки зрения разовачивания в production ]
1. *всё* включая 3rd party, должно ставится с сервера контролируемого теми, кто производит deployment. И это *обязаны* быть *те же файлы* (md5, а не версия/размер), что и использовались при разработке и тестирвоании.
2. сама по себе пересборка 3rd-party не обязательна, если проводился аудит другими средствами
[ С точки зрения разработки ]
1. Иметь сырцы 3rd-party желательно
2. Пересобирать их, перед выкладыванием на сервер компании - желательно
Хороший Project Manager в общем должен тянуть всё, внутрь, для снижения рисков. И посылать на курсы повышения квалификации разработчиков, если они утверждают, что это сложно/мешает/и т.д.
no subject
Date: 2012-08-06 17:33 (UTC)В случае python-а, и pypi.python.org это случается так часто, что если увидите человека который обновляет production с его - сразу задумайтесь о его квалификации.
no subject
Date: 2012-08-06 17:37 (UTC)исходники были на паре серверов и в бэкапе, но злобный хакер украл ключ и все удалил / жаба заставила закрыть исходники. Исходники можно скачать из каких-нибудь рапидшар (если повезет) -- Вася Пупкин делал копии и выкладывал, но... те ли это исходники? ;-)
no subject
Date: 2012-08-06 17:38 (UTC)no subject
Date: 2012-08-06 17:40 (UTC)ради бога. играйся сырцами
обычно в договорах прописана ответственность за подобные форсмажоры
соответственно:
>> действия в случае глюков в 3rd-party jar
ищется другая jar или пинаются разработчики текущей.
no subject
Date: 2012-08-06 17:40 (UTC)no subject
Date: 2012-08-06 17:49 (UTC)пнуть разработчика -- не всегда получится ;-)
no subject
Date: 2012-08-06 18:08 (UTC)1. это как бы очевидно. вопрос не в этом, а в п.2, точнее -- что делать, если баги есть, а апстрима, как такового уже нет.
[ С точки зрения разработки ]
1. Сырцы тоже требуют jar-ки для сборки, набор которых не обязательно пересекается с изначальным ;-)
2. Без этого ты даже не будешь уверен, что ты сможешь пересобрать эту jar ;-)
Можно еще компилятор и окружение припомнить, которые апдейтятся на сборочной системе, пока в какой-то момент не оказывается, что в текущем окружении просто скомпилировать то же самое, что было в прошлом году, не получается (правда с jar тут я не уверен -- долговременного опыта по поддержке нет). Или обратная ситуация, что продукт оказывается завязан на специфическое окружение, включая аппаратуру, на которое все молятся, т.к. восстановить в случае чего будет тяжело (это уже из практики пример).
no subject
Date: 2012-08-06 18:14 (UTC)Но в случае конкретно жабы и мавена или clojure и leiningen - jar с фиксированными версиями можно считать эквивалентом окружения, таким же как компилятор и ос.
И смена версий производится так же как переползание на новую версию среды разработки.
Почему для жабы приемлем второй вариант: потому что этим пользуется столько людей и столько раз я это сам делал, что есть уверенность в способности починить, если что-то сломается, а оно ломается нечасто (во всяком случае, пока не начинаются конфликты версий зависимостей, и то примерно понятно как чинить).
no subject
Date: 2012-08-06 18:18 (UTC)no subject
Date: 2012-08-06 18:19 (UTC)no subject
Date: 2012-08-06 18:35 (UTC)Ps. уже удалось покушать внедрение одной системы, в которой ключевая часть была OS решением, там ЕСЕСНО есть баг, который сообщество не может/не хочет исправить, а поставщик вроде как и готов исправить, но тогда теряется возможность в будущем апгрейда этих кусков кода
no subject
Date: 2012-08-06 18:37 (UTC)no subject
Date: 2012-08-06 18:43 (UTC)я уже предложил одному человеку подключиться на общий свитч и всунуть ему в сборку какую-нить пакость :-)
no subject
Date: 2012-08-06 18:51 (UTC)- жизненный цикл софта мал
- софт имеет минимум зависимостей
- это классический опенсорс, в котором нет денежного/анального наказания за простой.
Вот выше Максим привел абсолютно простой пример с питоном.
Мы тоже получали шишки.
no subject
Date: 2012-08-06 18:53 (UTC)no subject
Date: 2012-08-06 19:00 (UTC)У меня до сих пор виртуалка с VS6.0(+ правленые заголовки) + DDK(древней версии). Терять это нельзя ибо вариантов собрать софт больше нет.
no subject
Date: 2012-08-06 19:10 (UTC)Вообще говоря, я насмотрелся на линуксятину и стараюсь делать все как можно более стандартными средствами. Если принято мавен и репы - значит мавен и репы.
Если при этом что-то ломается - чиню у себя и иду трахать в мозг апстрим.
Клиентам, впрочем, стараюсь поставлять самозамкнутые продукты.
no subject
Date: 2012-08-06 19:27 (UTC)no subject
Date: 2012-08-06 19:43 (UTC)Оно, как минимум, собрано людьми, которых я знаю и которым я доверяю :)
Ну и ставлю подписанный или самосборный софт. Очень переживаю по поводу скайпа и все никак не возьмусь засунуть его в контейнер.
А вообще могу напомнить про сертификации разные на отсутствие недекларируемых возможностей в бинарных пакетах.
no subject
Date: 2012-08-06 19:50 (UTC)Если сторонние библиотеки поставляются с исходниками, "иметь их". Каждый раз их собирать, если вы их уже собрали и оттестиировали, не обязательно. Можно включить бинарные. Главное, чтобы результат был проверенным и предсказуемым. Цель - минимизация рисков, но не работа ради работы и не исходники ради исходников.
Пример. У меня в билд включается pdf. Ее тестирует и собирает специальный человек. Нужно ли мне ее заново собирать (такая возможность есть) из исходников, если человек ее собрал, закомитил ее и исходники от нее? Считаю, что необязатально.
no subject
Date: 2012-08-06 19:52 (UTC)прекратите каждый раз делать молотки, займитесь своей прикладной работой наконец.
no subject
Date: 2012-08-06 19:53 (UTC)Фрактал, ребе.
Главное, не забыть на фоне всего этого начать работать.
no subject
Date: 2012-08-06 20:01 (UTC)no subject
Date: 2012-08-06 20:04 (UTC)no subject
Date: 2012-08-06 20:05 (UTC)no subject
Date: 2012-08-06 20:20 (UTC)no subject
Date: 2012-08-06 20:21 (UTC)no subject
Date: 2012-08-06 20:21 (UTC)no subject
Date: 2012-08-06 20:43 (UTC)no subject
Date: 2012-08-06 20:55 (UTC)Ну и да, используйте apt-get, а не aptitude. Он чуть более тупой, но зато он быстрее, и как правило предлагает самое простое работающее решение, в отличие от aptitude, который придумывает их 100500 хитроумных, но 100400 из них включают в себя шаги в духе "вынести linux-image-2.6-686 и libc6".
no subject
Date: 2012-08-06 21:15 (UTC)no subject
Date: 2012-08-07 04:01 (UTC)no subject
Date: 2012-08-07 06:31 (UTC)no subject
Date: 2012-08-07 06:49 (UTC)no subject
Date: 2012-08-07 07:49 (UTC)no subject
Date: 2012-08-07 07:55 (UTC)