Сейчас мало кого удивишь инструментами управления зависимостями проекта вроде npm, composer, bundler, pip, maven, cargo и других. Их общий недостаток — невозможность управлять непосредственно средой выполнения. Такая задача решается через nvm, php-build, rvm, virtualenv, sdkman, rustup и прочие глобальные "манагеры" версий runtime, обычно написанные под Bash/Zsh. Следующий уровень "проблем" начинается, когда универсальный разработчик ежедневно занимается проектами с использованием совершенно разных технологий. Переменные окружения превращаются в месиво, а запуск шелла может занимать несколько секунд. Неизбежно начинаются бытовые ошибки в работе с этим зоопарком. Далее разброд и шатание настегает Continuous Integration & Delivery, где ручные танцы с бубном установки инструментов и активирования конкретных версий совершенно не приветствуются, а в идеале требуется в принципе максимально абстрагироваться от используемых технологий и довести процесс до примитивных нейтральных команд: подготовить к релизу, затегить, скачать, подготовить, построить, упаковать, выложить, проверить, одобрить(подписать), выкатить. Тут сам собой напрашивается инструмент, унифицировано работающий поверх уже существующих технологий,
который из себя и представляет FutoIn CID — FutoIn Continuous Integration & Delivery tool. Всё происходит на девственно чистом vagrant боксе debian/jessie64. В целях нахождения баланса между паранойей и удобством предлагается разрешить только установку пакетов без пароля. Подробнее в README. Для некоторых случаев Docker и JRE/JDK от Zulu требуется возможность устанавливать ключи для проверки подписи и дополнительные репозитории. Если есть опасения в рамках sudo, то это не так уж сложно сделать и руками, т.к. все исполняемые команды выводятся. В случае Vagrant'а нам можно всё по умолчанию. 
много буковок
 А теперь посмотрим, что же вышло. Мы видим полноценный бинарный артефакт, готовый для развёртывания. По умолчанию, CID также сделает GZIP версии найденных .js, .json, .css, .svg и *.txt файлов для использования вместе с модулем gzip_static в nginx. В качестве импровизированного манифеста создаётся файл .package.checksums с хешами SHA-512. Примечание: упаковка корня проекта лишь стандартное действие в отсутствии иной реализации. Например, maven или puppet сами создают артефакты  Примечание: по умолчанию CID сам находит наиболее поздний артефакт в выбранном пуле для развёртывания, если явно не указывать название. То же относится к тегам. Разумеется, для развёртывания на одной машине не очень серьёзного проекта такой шаг возможно пропустить и разворачивать прямо с VCS тега. Ввиду отсутствия тегов в примере, будем использовать живую ветку проекта. 
много буковок
 Повторим без изменений ветки и получим предупреждение об уже развёрнутой ревизии. С тегами и артефактами будет то же самое.  Подготовка конкретной версии, вызывая из локальной копии. Релиз следующей инкрементальной версии, не имея локальной копии на момент вызова. Стандартные действия: синхронизация с удалённым репозиторием, обновление всех возможных файлов метаданных, коммит, создание тега. Пример релиза самого CID:
 Проект может использовать дополнительные плагины. Например, CID обновляет версию в исходном коде и в CHANGELOG.  Если инструмент ещё не установлен, то будут сделаны все необходимые операции. В данном случае установлен RVM, а потом уже и актуальный Ruby 2.3.*. При этом RVM не будет грузиться при запуске шелла и стандартные переменные окружения не будут загрязнены.  По аналогии с небезызвестными package.json, composer.json, Cargo.toml и прочими представляет из себя описание проекта, если располагается в его корне. В нём допускается задавать общие настройки проекта, но наличие файла не является обязательным. При запуске, CID ищет возможные настройки среды развёртывания в корневой папке развёртывания — позволяет задать и настройки проекта, и настройки окружения (узел .env), а в домашней папке активного пользователя и в /etc/futoin/futoin.json — только узел .env. Примечание: узел .env не является аналогом и не заменяет "dotenv" файлы. Более подробно допустимые значения документированы в FTN16. Самые интересные узлы: Пример файла futoin.json в корне проекта: Все инструменты делятся на несколько типов. Один инструмент может сразу относится к нескольким. В перспективе, их может стать больше. Для вспомогательных нужд существует набор mixin'ов, часть из которых уже включена в SubTool. Поддерживаются практически все распространённые дистрибутивы Linux: от CentOS и Debian до ArchLinux и Gentoo. Добавлена экспериментальная поддержка macOS. Нет подходящего оборудования — помощь в тестировании крайне приветствуется. В качеству proof-of-concept поддерживаются самые различные языки программирования и сопутствующие инструменты: от PHP, Python и Ruby до Go, Rust и Scala. Возможность по расширению и добавлению кастомных плагинов почти неограниченна. Также поддерживаются три разных VCS: Git, Mercurial и Subversion. Поддержка RMS реализована принципиально. Для целей тестирования пока работает только scp, но основной прицел на Archiva, Artifactory и Nexus. Поддержка unit test'ов полагается на инструменты сборки проектов (make, gradle, grunt и т.д.), а вот сбор результатов пока не определён. Рекомендации также приветствуются. Процесс криптографического подписывания пока не определён. Требуется проанализировать и найти общий знаменатель для use case'ов. В случае необходимости поддержка *BSD предположительно потребует минимальных усилий, а вот поддержка Windows с упором на .Net скорее потребует альтернативную специализированную реализацию. Интерфейс для миграции данных предусмотрен, но пока не имеет стандартной реализации. Движимая ленью, патологическим неприятием монотонной возни и страстью к автоматизации, родилась обобщающая концепция для практически всех возможных технологий. К ней добавилась реализация в виде конкретного инструмента FutoIn CID. Безусловно требуется серьёзная шлифовка и обкатка на практике. Помимо упрощения жизни разработчика, дальним прицелом является автоматизация инфраструктуры DevOps. Разумеется, это не первый инструмент, поддерживающий различные технологии, но возможно первый, который может работать вообще без настройки, улучшая производительность труда и уменьшая количество повседневных ошибок. → GitHub
→ Python Package Index
→ FTN16 Draft Свободный художник на все руки