Я отвечаю за наше внутреннее программное обеспечение при запуске на основе данных. Мы строим все наше программное обеспечение в python. Я и другой член моей команды постоянно спорим: замораживаем ли мы наши требования к зависимостям в нашем файле setup.py на определенный c набор версий?
Чтобы дать вам представление о наших текущая настройка:
- Наше основное программное обеспечение представляет собой одну библиотеку python, содержащую около 30 тыс. строк кода.
- Библиотека используется только для внутренних целей, чтобы производить данные, которые мы затем продаем.
- Я использую файл setup.py для управления зависимостями пакетов.
- У нас есть достойное модульное тестирование и автоматизированный CI l oop, охват около 70%.
- На данный момент в команде всего три разработчика.
До сих пор в файле setup.py я думал, что лучше всего не указывать, какая версия пакета мне нужна, Я пытался оставить это как можно более покорным. Чтобы привести несколько более продвинутый пример c, я свяжу файл setup.py с airflow, который, кажется, делает то же самое (хотя вокруг немало> =): https://github.com/apache/airflow/blob/master/setup.py
Я указывал версию для данной зависимости только в том случае, если мы обнаружили ошибку, вызванную обновлением и нарушением нашей зависимости. У нас есть непрерывное интеграционное тестирование, которое обычно (но не всегда) отлавливает эти ошибки. Когда он обнаруживает поломку, я должен выяснить, кто является виновником, и обычно просто исправить версию на последнюю, которая сработала. Лучшая практика? Конечно, нет. Но это то, для чего у нас есть возможности.
Теперь я думаю запустить pip freeze для набора версий зависимых пакетов, которые работают, и использовать выходные данные и явно зафиксировать версии в наборе, который работает, обновления зависимостей. будь проклят! Это вызвано несколькими соображениями:
- Наша команда мала, слишком мала, чтобы искать ошибки из pandas обновления, когда старая версия работала нормально.
- Мы не Мы публикуем данные или публикуем программное обеспечение sh или даже продаем программное обеспечение. Все наше программное обеспечение предназначено исключительно для внутреннего использования, поэтому мы обладаем высокой степенью контроля над нашей средой и вариантами использования.
- Мы можем увеличивать пакеты в любое время, возможно, ежемесячно, но это будет сделано по заранее выделенному время, а не только всякий раз, когда возникает ошибка.
Мой вопрос: кто-нибудь был в подобной позиции контроля среды для внутреннего использования программного обеспечения раньше? Если так, как вы управляли своей зависимой версией? Те, кто не имеет, но опытные DevOps / SWEs, что бы вы сделали?