Как далеко Вы берете управление версиями? [закрытый]
Другой (немного более компактный) способ:
name, first, second = a.split('_')
first_range = range(int(first[1]), int(first[3]) + 1)
second_range = range(int(second[1]), int(second[3]) + 1)
res = ['{}_{}_{}'.format(name, i, j) for j in second_range for i in first_range]
# ['NAME_1_3', 'NAME_2_3', 'NAME_1_4', 'NAME_2_4', 'NAME_1_5', 'NAME_2_5']
8 ответов
Возможно, вам не следует хранить «всю виртуализированную систему сборки» в виде гигантского двоичного файла. Если вы хотите создать версию своего приложения, вы создаете версию исходного кода, а не скомпилированного двоичного файла.
Многие магазины делают в системе управления версиями шаги для воссоздания сервера сборки. Затем вам нужен один фиксированный образ (стандартная, готовая к установке ОС), а также небольшое количество файлов (что на нем установить и как). В некоторых местах даже сервер должен перестраивать приложение из исходного кода при чистой установке ОС для каждого развертывания / перезагрузки.
Создание версии образа самой ОС в виде гигантского двоичного файла не так полезно. Вы не можете ветвиться. Вы не можете слиться. Вы не можете дифференцироваться. В чем смысл? Вы можете сэкономить место, если ваша VCS может делать двоичные различия, но на это, вероятно, уходит тонна ресурсов процессора и памяти, и если они находятся на пике «диск дешевый», то нет причин делать жизнь мучительной, просто для экономии места на диске.
Либо сохраняйте сценарии установки / библиотеки в VC и перестроить образ виртуальной машины по мере необходимости, или просто хранить образы виртуальной машины в обычных файлах. Я не вижу смысла помещать изображения в VCS.
То, что я всегда помещал в систему контроля версий:
- исходный код и файлы сборки: минимум, необходимый для сборки бинарных файлов.
- наборы тестов
То, что я никогда не помещал в контроль версий:
- встроенные бинарные файлы: они могут быть воссозданы из системы контроля версий, и если я знаю, что могу Нужен конкретный выпуск немедленно, я храню их в файловой системе аналогично ядру Linux.
То, что я помещаю в управление версиями в зависимости от проекта:
- цепочка сборки: я не Я включаю его в систему контроля версий, когда доверяю провайдеру или могу воссоздать среду (Apple's Xcode, инструменты с открытым исходным кодом, такие как gcc или doxygen, ...). Я помещаю его в систему контроля версий, когда он специально предназначен для проекта (например, домашняя цепочка кросс-компиляции) и когда мне нужно воссоздать бинарный файл в точности так, как он был создан для доставки (для поиска гейзенгов, когда может быть задействован какой-либо компонент, из код для ОС или компилятора).
Контроль версий, который невозможно создать без него. Таким образом, цепочка инструментов не может быть легко воссоздана - в версии есть смысл контролировать это. Поскольку цепочка инструментов (и исходный код) находится под управлением версией, нет необходимости архивировать продукты сборки - или, по крайней мере, не после завершения тестирования сборки.
Для довольно экстремального подхода проверьте Весту .
Подход Vesta основан на следующих основах:
Неизменное, бессмертное, версионное хранилище всех источников и инструментов. В отличие от ClearCASE, Vesta использует явные номера версий, а не представления.
Полные описания конфигурации на основе источника. Под полным мы подразумеваем чтобы в описании были указаны все элементы, участвующие в сборке. Каждый аспект вычислительной среды, включая инструменты, библиотеки, заголовочные файлы, и переменные среды, полностью описаны и контролируются Вестой. По на основе исходного кода, мы подразумеваем, что описания конфигурации указывают, как построить система с нуля, использующая только неизменяемые источники (т. е. не производные файлы). Сами описания являются версионными и неизменными источниками, а их значение постоянно; конкретное описание верхнего уровня всегда описывает точно одну и ту же сборку, используя одни и те же источники, даже после новых версий источники и описания были созданы.
Автоматическое управление производными файлами. Хранение и наименование производных файлов автоматически управляется хранилищем хранилища Vesta, тем самым облегчая бремя сборки нескольких выпусков или сборки для нескольких целевых платформ.
Кэширование всего сайта на всех сборочных работах. Vesta имеет общий кеш сайта результатов сборки, чтобы разработчики могли извлечь пользу из сборок друг друга.
Автоматическое определение зависимостей. Конструктор Vesta динамически обнаруживает и записывает все зависимости, поэтому ни одна из них не может быть исключена из-за ошибки человека. Под динамически мы подразумеваем, что сборщик определяет, какие источники фактически используются в процесс построения результата сборки и записи зависимостей только на их. Анализ зависимостей Весты не использует никаких знаний о как работают инструменты сборки; таким образом, он не зависит от семантики в терминологии Гюнтера [7]. Например, если компилятор читает файл foo.h в процессе компиляции файла foo.c, Веста будет предполагать, что вывод компилятора зависит на всех foo.h, даже если инструмент со знанием C может найти отдельные элементы в foo.h, которые могут быть изменены без изменения результата компиляции.
Здравый смысл, а не суета ИТ, должен определять, как вы управляете и настраиваете свою цепочку инструментов. Если у вас стандартное оборудование и вы часто добавляете разработчиков, сохранение встроенного набора инструментов в виде изображений имеет смысл; но изображения не должны быть под контролем версий. Если у вас 50 разработчиков, система управления конфигурацией для вашей цепочки инструментов сократит накладные расходы; если у вас есть 5 разработчиков, это больше затрат - еще одна система для изучения.
Итак, мешает ли Git тому, что вы хотите делать? Или вы получаете запросы, потому что пользователи пытаются сказать, что вы должны сделать вашу систему более сложной, потому что вы могли бы?
Если ваши инструменты сборки являются зрелыми, тогда даты сборки может быть достаточно, чтобы определить версии инструментов, которые были используемый. Вы можете попросить ваш скрипт сценария написать текстовый файл ваших инструментов сборки и их версий, аналогично списку зависимостей.
Если вы используете быстро меняющиеся внутренние инструменты или альфа / бета-версии проектов, находящихся в стадии активной разработки, то было бы хорошее обоснование для помещения инструментов сборки под контроль версий - но это решило бы не ту проблему , Зачем вам строить с нестабильным набором инструментов ???
Я придерживаюсь классического ответа о хранении всего, что необходимо для создания конечного продукта. Двоичные и промежуточные файлы не нужны, но включены все сценарии, которые используются в сборке.
Я использую свои репозитории git в качестве резервных копий, сохраняя голые клоны как минимум в двух местах, поэтому стараюсь не оставлять ничего, что необходим для сборки, но я не беспокоюсь о сохранении чего-либо временного.
Я бы сказал, что здесь есть порядок операций:
Если им нужно хранить файлы, используйте файловую систему.
Если им нужно отслеживать изменения, используйте контроль версий.
Если им нужно отслеживать отношения с данными, используйте базу данных.
Чем сложнее требования, тем сложнее решение. Но дисциплина нужна тем, кто хочет более сложного решения; в эти нестабильные времена нужно не тратить время зря.
Я использую контроль исходного кода для всей моей цепочки инструментов. Как указано выше, это имеет большие преимущества:
- Все используют одни и те же инструменты, поэтому нам никогда не придется беспокоиться о несовместимости.
- Машина сборки создает те же артефакты, что и разработчики.
- Мы всегда можем воссоздать любой артефакт в любой момент в будущем, потому что набор инструментов полностью обновлен.
Я провел черту где-то выше операционной системы; Вот что я представил:
Windows
- SDK платформы (сейчас Windows SDK )
- Visual C ++ Toolkit , затем позже лицензированный Visual C ++, теперь Windows SDK включает компиляторы .
Linux
- gcc
- make
- glibc
Оба
- JDK
Некоторые проблемы, с которыми я столкнулся при попытке сделать это, были:
- В Linux такие вещи, как Perl и gcc встраивают свой установочный каталог в свои исполняемые файлы. Это означает, что разработчики и сборочная машина должны запускать сценарий после извлечения, чтобы обновить их, вставив их пути в двоичные файлы.
- На любой платформе у вас есть гораздо более длинный и более сложный список параметров компиляции, в котором указывается каждый заголовок и каталог библиотеки; Подобные вещи выполняются автоматически при «нормальной» установке. Одна из тех вещей, которые неочевидны, заключается в том, что
crti.oи друзья - это то, что по умолчанию находится в/ usr / libи фактически принадлежитglibc-devel.(илиlibc6-dev), поэтому он не находится в файловой системе, если не установленglibc-devel. - Для Windows все компиляторы после 2003 года используют параллельные сборки, поэтому, чтобы избежать процедуры установки на целевой машине, мне пришлось копать их и размещать рядом с исполняемыми файлами компилятора в управлении исходным кодом.
- Windows SDK v6.1 с компиляторами (и без помощи / примеров) огромен: 427 МБ, если я считаю правильно.
Я начал пытаться использовать Apache Ivy (аналогично Maven ), чтобы помочь мне управлять цепочкой инструментов, но я еще не видел примеров использования Ivy или Maven для управления чем-то, что не является файлом Java .jar . Я не знаю, смогу ли я управлять такими вещами, как компилятор C.
В идеале я хочу, чтобы либо проверка контроля над исходным кодом, либо Ivy или Maven решили иметь все инструменты и библиотеки в файловой системе разработчика, готовые к использованию. , Но я' Я начинаю думать, что требовать от разработчика установки небольшого количества критических вещей, таких как Windows SDK или пакеты gcc и glibc-devel , не такая уж плохая идея. Как уже упоминалось выше, это вопрос 5 или 50 разработчиков, и время, затрачиваемое на создание такого решения.