![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
исходники: иметь или не иметь?
С некоторыми сотоварищами развернулась интересная дискуссия. Как известно для того, чтобы собрать и задеплоить свой продукт на жабе требуется N-ное количество сторонних пакетиков в виде JAR-файлов.
Так вот, я доказываю, что для коммерческого продукта необходимо иметь полный и замкнутый цикл разработки, который включает в себя полное дерево исходников и пересборку 3rd-party jar-файлов, любое обращение к сети во время сборки должно быть запрещено.
Противоположная точка зрения -- все выкачивается из интернета в виде бинарных jar-файликов (в идеале при каждой сборке, как вариант -- кашируется 1 раз для локального использования).
Как по вашему -- кто прав и почему? ;-)
Так вот, я доказываю, что для коммерческого продукта необходимо иметь полный и замкнутый цикл разработки, который включает в себя полное дерево исходников и пересборку 3rd-party jar-файлов, любое обращение к сети во время сборки должно быть запрещено.
Противоположная точка зрения -- все выкачивается из интернета в виде бинарных jar-файликов (в идеале при каждой сборке, как вариант -- кашируется 1 раз для локального использования).
Как по вашему -- кто прав и почему? ;-)
no subject
no subject
no subject
no subject
исходники были на паре серверов и в бэкапе, но злобный хакер украл ключ и все удалил / жаба заставила закрыть исходники. Исходники можно скачать из каких-нибудь рапидшар (если повезет) -- Вася Пупкин делал копии и выкладывал, но... те ли это исходники? ;-)
no subject
ради бога. играйся сырцами
обычно в договорах прописана ответственность за подобные форсмажоры
соответственно:
>> действия в случае глюков в 3rd-party jar
ищется другая jar или пинаются разработчики текущей.
no subject
пнуть разработчика -- не всегда получится ;-)
no subject
no subject
Ps. уже удалось покушать внедрение одной системы, в которой ключевая часть была OS решением, там ЕСЕСНО есть баг, который сообщество не может/не хочет исправить, а поставщик вроде как и готов исправить, но тогда теряется возможность в будущем апгрейда этих кусков кода
no subject
Уже сколько раз обжигались:
- автор библиотеки сошел сума/вши захватили датцентр/молния ударила прямо в сервер.
И мы потеряли линк на библиотеку. Да, их будет еще много, форки там итд. Но это не вариант.
- у кастомера на объекте может не быть доступа к интернету(Служба Безопасности выдает интернет по талонам в большие православные праздники)
Кто работал с кровавыми энтерпрайзами знают как это бывает.
- C вероятностью 99.9% сторонние либы надо будет патчить. И лучше держать у себя их вместе со своими накатанными патчами.
no subject
В случае python-а, и pypi.python.org это случается так часто, что если увидите человека который обновляет production с его - сразу задумайтесь о его квалификации.
no subject
no subject
- жизненный цикл софта мал
- софт имеет минимум зависимостей
- это классический опенсорс, в котором нет денежного/анального наказания за простой.
Вот выше Максим привел абсолютно простой пример с питоном.
Мы тоже получали шишки.
no subject
[ С точки зрения разовачивания в production ]
1. *всё* включая 3rd party, должно ставится с сервера контролируемого теми, кто производит deployment. И это *обязаны* быть *те же файлы* (md5, а не версия/размер), что и использовались при разработке и тестирвоании.
2. сама по себе пересборка 3rd-party не обязательна, если проводился аудит другими средствами
[ С точки зрения разработки ]
1. Иметь сырцы 3rd-party желательно
2. Пересобирать их, перед выкладыванием на сервер компании - желательно
Хороший Project Manager в общем должен тянуть всё, внутрь, для снижения рисков. И посылать на курсы повышения квалификации разработчиков, если они утверждают, что это сложно/мешает/и т.д.
no subject
1. это как бы очевидно. вопрос не в этом, а в п.2, точнее -- что делать, если баги есть, а апстрима, как такового уже нет.
[ С точки зрения разработки ]
1. Сырцы тоже требуют jar-ки для сборки, набор которых не обязательно пересекается с изначальным ;-)
2. Без этого ты даже не будешь уверен, что ты сможешь пересобрать эту jar ;-)
Можно еще компилятор и окружение припомнить, которые апдейтятся на сборочной системе, пока в какой-то момент не оказывается, что в текущем окружении просто скомпилировать то же самое, что было в прошлом году, не получается (правда с jar тут я не уверен -- долговременного опыта по поддержке нет). Или обратная ситуация, что продукт оказывается завязан на специфическое окружение, включая аппаратуру, на которое все молятся, т.к. восстановить в случае чего будет тяжело (это уже из практики пример).
no subject
no subject
no subject
no subject
no subject
прекратите каждый раз делать молотки, займитесь своей прикладной работой наконец.
no subject
no subject
no subject
no subject
Ну и да, используйте apt-get, а не aptitude. Он чуть более тупой, но зато он быстрее, и как правило предлагает самое простое работающее решение, в отличие от aptitude, который придумывает их 100500 хитроумных, но 100400 из них включают в себя шаги в духе "вынести linux-image-2.6-686 и libc6".
no subject
no subject
no subject
no subject
no subject
Но в случае конкретно жабы и мавена или clojure и leiningen - jar с фиксированными версиями можно считать эквивалентом окружения, таким же как компилятор и ос.
И смена версий производится так же как переползание на новую версию среды разработки.
Почему для жабы приемлем второй вариант: потому что этим пользуется столько людей и столько раз я это сам делал, что есть уверенность в способности починить, если что-то сломается, а оно ломается нечасто (во всяком случае, пока не начинаются конфликты версий зависимостей, и то примерно понятно как чинить).
no subject
я уже предложил одному человеку подключиться на общий свитч и всунуть ему в сборку какую-нить пакость :-)
no subject
no subject
У меня до сих пор виртуалка с VS6.0(+ правленые заголовки) + DDK(древней версии). Терять это нельзя ибо вариантов собрать софт больше нет.
no subject
Вообще говоря, я насмотрелся на линуксятину и стараюсь делать все как можно более стандартными средствами. Если принято мавен и репы - значит мавен и репы.
Если при этом что-то ломается - чиню у себя и иду трахать в мозг апстрим.
Клиентам, впрочем, стараюсь поставлять самозамкнутые продукты.
no subject
Оно, как минимум, собрано людьми, которых я знаю и которым я доверяю :)
Ну и ставлю подписанный или самосборный софт. Очень переживаю по поводу скайпа и все никак не возьмусь засунуть его в контейнер.
А вообще могу напомнить про сертификации разные на отсутствие недекларируемых возможностей в бинарных пакетах.
no subject
no subject
Фрактал, ребе.
Главное, не забыть на фоне всего этого начать работать.
no subject
no subject
no subject
no subject
Если сторонние библиотеки поставляются с исходниками, "иметь их". Каждый раз их собирать, если вы их уже собрали и оттестиировали, не обязательно. Можно включить бинарные. Главное, чтобы результат был проверенным и предсказуемым. Цель - минимизация рисков, но не работа ради работы и не исходники ради исходников.
Пример. У меня в билд включается pdf. Ее тестирует и собирает специальный человек. Нужно ли мне ее заново собирать (такая возможность есть) из исходников, если человек ее собрал, закомитил ее и исходники от нее? Считаю, что необязатально.
no subject
no subject
no subject