Другой (немного более компактный) способ:
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']
Возможно, вам не следует хранить «всю виртуализированную систему сборки» в виде гигантского двоичного файла. Если вы хотите создать версию своего приложения, вы создаете версию исходного кода, а не скомпилированного двоичного файла.
Многие магазины делают в системе управления версиями шаги для воссоздания сервера сборки. Затем вам нужен один фиксированный образ (стандартная, готовая к установке ОС), а также небольшое количество файлов (что на нем установить и как). В некоторых местах даже сервер должен перестраивать приложение из исходного кода при чистой установке ОС для каждого развертывания / перезагрузки.
Создание версии образа самой ОС в виде гигантского двоичного файла не так полезно. Вы не можете ветвиться. Вы не можете слиться. Вы не можете дифференцироваться. В чем смысл? Вы можете сэкономить место, если ваша VCS может делать двоичные различия, но на это, вероятно, уходит тонна ресурсов процессора и памяти, и если они находятся на пике «диск дешевый», то нет причин делать жизнь мучительной, просто для экономии места на диске.
Либо сохраняйте сценарии установки / библиотеки в VC и перестроить образ виртуальной машины по мере необходимости, или просто хранить образы виртуальной машины в обычных файлах. Я не вижу смысла помещать изображения в VCS.
То, что я всегда помещал в систему контроля версий:
То, что я никогда не помещал в контроль версий:
То, что я помещаю в управление версиями в зависимости от проекта:
Контроль версий, который невозможно создать без него. Таким образом, цепочка инструментов не может быть легко воссоздана - в версии есть смысл контролировать это. Поскольку цепочка инструментов (и исходный код) находится под управлением версией, нет необходимости архивировать продукты сборки - или, по крайней мере, не после завершения тестирования сборки.
Для довольно экстремального подхода проверьте Весту .
Подход Vesta основан на следующих основах:
Неизменное, бессмертное, версионное хранилище всех источников и инструментов. В отличие от ClearCASE, Vesta использует явные номера версий, а не представления.
Полные описания конфигурации на основе источника. Под полным мы подразумеваем чтобы в описании были указаны все элементы, участвующие в сборке. Каждый аспект вычислительной среды, включая инструменты, библиотеки, заголовочные файлы, и переменные среды, полностью описаны и контролируются Вестой. По на основе исходного кода, мы подразумеваем, что описания конфигурации указывают, как построить система с нуля, использующая только неизменяемые источники (т. е. не производные файлы). Сами описания являются версионными и неизменными источниками, а их значение постоянно; конкретное описание верхнего уровня всегда описывает точно одну и ту же сборку, используя одни и те же источники, даже после новых версий источники и описания были созданы.
Автоматическое управление производными файлами. Хранение и наименование производных файлов автоматически управляется хранилищем хранилища Vesta, тем самым облегчая бремя сборки нескольких выпусков или сборки для нескольких целевых платформ.
Кэширование всего сайта на всех сборочных работах. Vesta имеет общий кеш сайта результатов сборки, чтобы разработчики могли извлечь пользу из сборок друг друга.
Автоматическое определение зависимостей. Конструктор Vesta динамически обнаруживает и записывает все зависимости, поэтому ни одна из них не может быть исключена из-за ошибки человека. Под динамически мы подразумеваем, что сборщик определяет, какие источники фактически используются в процесс построения результата сборки и записи зависимостей только на их. Анализ зависимостей Весты не использует никаких знаний о как работают инструменты сборки; таким образом, он не зависит от семантики в терминологии Гюнтера [7]. Например, если компилятор читает файл foo.h в процессе компиляции файла foo.c, Веста будет предполагать, что вывод компилятора зависит на всех foo.h, даже если инструмент со знанием C может найти отдельные элементы в foo.h, которые могут быть изменены без изменения результата компиляции.
Здравый смысл, а не суета ИТ, должен определять, как вы управляете и настраиваете свою цепочку инструментов. Если у вас стандартное оборудование и вы часто добавляете разработчиков, сохранение встроенного набора инструментов в виде изображений имеет смысл; но изображения не должны быть под контролем версий. Если у вас 50 разработчиков, система управления конфигурацией для вашей цепочки инструментов сократит накладные расходы; если у вас есть 5 разработчиков, это больше затрат - еще одна система для изучения.
Итак, мешает ли Git тому, что вы хотите делать? Или вы получаете запросы, потому что пользователи пытаются сказать, что вы должны сделать вашу систему более сложной, потому что вы могли бы?
Если ваши инструменты сборки являются зрелыми, тогда даты сборки может быть достаточно, чтобы определить версии инструментов, которые были используемый. Вы можете попросить ваш скрипт сценария написать текстовый файл ваших инструментов сборки и их версий, аналогично списку зависимостей.
Если вы используете быстро меняющиеся внутренние инструменты или альфа / бета-версии проектов, находящихся в стадии активной разработки, то было бы хорошее обоснование для помещения инструментов сборки под контроль версий - но это решило бы не ту проблему , Зачем вам строить с нестабильным набором инструментов ???
Я придерживаюсь классического ответа о хранении всего, что необходимо для создания конечного продукта. Двоичные и промежуточные файлы не нужны, но включены все сценарии, которые используются в сборке.
Я использую свои репозитории git в качестве резервных копий, сохраняя голые клоны как минимум в двух местах, поэтому стараюсь не оставлять ничего, что необходим для сборки, но я не беспокоюсь о сохранении чего-либо временного.
Я бы сказал, что здесь есть порядок операций:
Если им нужно хранить файлы, используйте файловую систему.
Если им нужно отслеживать изменения, используйте контроль версий.
Если им нужно отслеживать отношения с данными, используйте базу данных.
Чем сложнее требования, тем сложнее решение. Но дисциплина нужна тем, кто хочет более сложного решения; в эти нестабильные времена нужно не тратить время зря.
Я использую контроль исходного кода для всей моей цепочки инструментов. Как указано выше, это имеет большие преимущества:
Я провел черту где-то выше операционной системы; Вот что я представил:
Windows
Linux
Оба
Некоторые проблемы, с которыми я столкнулся при попытке сделать это, были:
crti.o
и друзья - это то, что по умолчанию находится в / usr / lib
и фактически принадлежит glibc-devel.
(или libc6-dev
), поэтому он не находится в файловой системе, если не установлен glibc-devel
. Я начал пытаться использовать Apache Ivy (аналогично Maven ), чтобы помочь мне управлять цепочкой инструментов, но я еще не видел примеров использования Ivy или Maven для управления чем-то, что не является файлом Java .jar
. Я не знаю, смогу ли я управлять такими вещами, как компилятор C.
В идеале я хочу, чтобы либо проверка контроля над исходным кодом, либо Ivy или Maven решили иметь все инструменты и библиотеки в файловой системе разработчика, готовые к использованию. , Но я' Я начинаю думать, что требовать от разработчика установки небольшого количества критических вещей, таких как Windows SDK или пакеты gcc
и glibc-devel
, не такая уж плохая идея. Как уже упоминалось выше, это вопрос 5 или 50 разработчиков, и время, затрачиваемое на создание такого решения.