Комментарии 67
Т.е. на каждый мердж в мастер:
- TeamCity собирает проект/набор компонент/артефактов, выполняет набор юнит тестов
- TeamCity деплоит полученные артефакты в Nexus(Artifactory)
- TeamCity собирает финальный *tar.gz с набором скриптов/конфигураций
- TeamCity доставляет собранный *tar.gz на нужную тачку(scp ?), где все это должно раниться
- TeamCity стопает текущее окружение, если запущено (UAT/PAR/QA/SIT/whatever) и чистит все что нужно почистить
- TeamCity разворачивает *tar.gz
- TeamCity запускает в нужной последовательности весь набор инициализации финального продукта
И это на каждый пуш в мастер, я правильно понимаю?
К примеру, у меня была гора планов сборки приложения, в зависимости от конкретного объекта, в которую были вложены разные ветки (dev, stable, и так далее). Те, в свою очередь, могли собираться или по временным триггерам (те же ночники), так и после N коммитов, или же вовсе лишь вручную.
Персонально у меня автоматом, как правило, собирался только next-release, стейбл же собирался либо вручную, либо по воскресеньям в ночь на пнд. Деплой можно было к конкретно взятому билду подвесить автоматом после сборки, либо же выполнить вручную.
В общем, всё можно сделать достаточно гибко. Никакого оверхеда и сборки после каждого коммита не было. Что же касается самих скриптов — я предпочитал создавать темплейты из скрипта, распиленного на степы, и потом создавать из них конкретные билды, лишь подменяя параметры в зависимости от стенда. Единократно требовалось бросить ключи на тачку с агента, и после этого всё было в практически однокнопочном режиме.
Надо было сделать некий интерфейс для разрабов, чтобы те могли создавать и копировать схемы оракла из прода в дев. Чем писать свой велосипед — сделал несколько джобов, которые читали вводные данные и запускали скрипты.
Всё, полчаса-час ожидания — и можно сидеть и проверять зарепорченный баг. А я могу сходить попить чаю, вместо того, чтоб сидеть тридцать минут в консоли и стучать в клавиатуру, как заведённый щелкунчик.
Главный вопрос в этом.
и всякие мелкие полезностиА есть где-то весь список забавных фразочек из шапки?
Вот, пожалуйста =)
- Глаз страуса больше, чем его мозг, %username%.
- Мне нужна твоя одежда и мотоцикл, %username%.
- В наборе детских кубиков буквы «Х», «Й» и «У» всегда находятся на одном кубике, %username%.
- Сегодня вас ждёт приятная неожиданность, %username%!
- Хорошая погода, не правда ли, %username%?
- Попытка — первый шаг к провалу, %username%.
- Продолжайте кликать, %username%! Во имя всего святого, продолжайте кликать!
- Шоколад ни в чем не виноват, %username%.
- Береги коленки, %username%!
- Bite my shiny metal ass, %username%
- Попасть сюда сложно, %username%. Выход не могут найти даже старожилы.
- Тут никого нет, %username%! Никого! Никого, кроме тебя!
- Вы не дождетесь новых приветствий, %username%.
- Люди в тюрьме меньше времени сидят, чем вы работаете на этом проекте, %username%.
- Если руки золотые, то не важно откуда они растут, %username%.
- Вгрущить — это то, что наша система умеет делать лучше всего, %username%.
- Проект развивает мелкую моторику рук и тренирует глаза. Все время надо прищелкивать, %username%!
- Косячим — так косячим, чиним — так чиним, %username%!
- Что-то пошло не так, %username%.
- Надо прибить план гвоздями, %username%
- Машина едет, а мы строим дорогу перед ней, %username%.
- Мы с одного конца печём батон, который с другого конца едят, %username%.
- Буквы нужны для проверки двух теорий, %username%.
- Прилетело НЛО и унесло ваши отчеты, %username%.
- <table_name> — это изюм нашего хранилища, %username%.
- Что сделать, чтобы оно не висло, %username%?
- Мы написали ошибку ПО 1000 лет тому назад, %username%.
- Про проект или хорошо, или никак, %username%.
- Ну какой инженер может спокойно пройти мимо забитого на 100% диска, %username%?
- <Название_системы> не сдается, %username%!
- Не найдены микроданные — это нормально, %username%.
- Эксперименты, инновации, ПСИ, %username%!
- <Название_системы>ик болеет, %username%.
- Солар на буквах ушёл в запой, %username%.
- По срочности: это нежно до завтра до утра понять, %username%.
- На <Название_формы> можно только смотреть… это созерцательная форма, %username%.
- Сортировка строк в Кассандре происходит с божьей помощью, %username%.
- Непоправимое улучшение было выполнено, %username%.
- Костыли в шкафу, %username%.
- Процесс разборок запущен, %username%.
- У нас что с Каччандрой, %username%?
- Я тоже позвонил Андрею, %username%.
- Ничего ведь просто так не бывает — есть причина, есть следствие, %username%.
- Ушки пчелы, перья жабы, кровь тухлого абрикоса и немного времени решат твою задачу, %username%.
- У нас в проекте аналитики ходят с мылом, веревкой и загадочно улыбаются, %username%.
- Если ты не тестировщик, %username%, не ломай тест. Это должны делать профессионалы.
- Конвейеру похер-мороз, %username%. Он еще и не такие шаги обработает.
- Оказалось не все так ужасно, %username%.
- У Кассандры одна извилина, %username%.
- Запрещать разработчикам разрабатывать без ФС — это ограничивать их свободу творчества, %username%.
- С первой виртуалкой какой-то огурец мозга, %username%.
- Не стоит делать /usr/share/apache-tomcat-8.0.23/bin/startup.sh от рута, %username%. Это нарушает пространственно-временной континуум.
- Не знаю что это, %username%, но в хозяйстве явный прибыток.
- Салават не хочет получить лососями, %username%. Он не овнер!
- Если ошибка в программе может произойти, она произойдет, %username%.
- Здесь могла бы быть ваша реклама, %username%. Но, увы, её тут нет.
- Для хорошего программиста он слишком часто копировал чужой код, %username%.
- Бугагагашенька, %username%.
- Спокойной ночи, в случае апокалипсиса — удачи, %username%.
- Только начнёшь работать, обязательно кто-нибудь разбудит, %username%.
- %username%, помни правило простое. Работаешь сидя, отдыхай — стоя!
Я был на собеседовании в КРОКе.
Мне они сразу сказали, что проект срочный
и придётся оставаться в офисе до "после 23:00".
Т.е. заведомо нанимали меньше народа,
чтобы каждый работал не только за себя,
но и за того парня.
Мне понравилось такое на XL deploy делать, но он сильно платный.
Мне уже стало интересно как у вас все реализовано :)
Вот смотрите есть у нас DB, backend, frontend. И они зависят друг от друга по нисходящей. Миграция DB ведет к рестарту backend, а затем frontend. Апдейт версии backend влечет рестарт frontend. Получаем у нас есть три возможных артифакта и 7 вариантов деплоя.
И как реализовать деплой не плодя плэйбук на каждый случай? Я представляю что это можно решить через группы. И/или расписать все шаги и на каждом шаге проверять условия. Но мне кажется, что поддержка такого будет не слаще чем скриптов. Помним что пример абстрактный, и компонентов у нас на самом деле несколько десятков.
для сценариев shell тоже есть
1) фрэймворки
2) библиотеки
3) соглашения по исползованию (coding conventions)
4) пакетирование
…
тысячи их
N) PROFIT!!!
мне хочется выгнать вон из профессии ссаными тряпками всех,
кто в 2015 пишет так,
как будто на дворе 1995 г.
хуже сырого говнокода на баше
может быть только говнокод на PERL
ну реально
дюди прочитали самую тупую и неудачную книжку
(или вообще никакой)
и плодят уродство, с которым потом
нормальным доведётся страдать
и ещё за это
получают неплохие зарплаты
как после этого нормально относиться
к КРОКу и подобным конторам?!
https://github.com/alebcay/awesome-shell
https://github.com/awesome-lists/awesome-bash
https://c9.io/nopolitica/awesome-shell
Вот честно, — я бы избавился от такого Дениса
под любым предлогом!
Я был в конторах, где десятки таких «гениев»
годами (если не десятилетиями) копили
тонны такого говнокода и говноинфрастуктуры
и я бы не согласился разгребать ЭТО
ни за какие деньги
потому что здоровье дороже
и нервов не хватит.
Плохо что у нас такие КРОКи — «короли госзаказа»
у буржуев на западе
подобная контора (а у них там всё так)
дожила бы ровно до первого грамотного аудита.
Относительно кода, возможно, в посте недостаточно подчеркнул, но я выносил общий код в библиотеки, использовал coding conventions…
Про какую книжку, кстати, Вы говорите? Я любитель юниксов, командной строки и всего такого, много лет пользуюсь шеллом и довольно много материала изучил по этой теме.
(или «заценить», глянув беглым взглядом на количество «звёздочек»,
количество контрибуторов и дату коммита).
Сейчас для баша все «coding conventions»
заканчиваются "… а лучше напишите playbook или возьмите готовый".
книжки есть просто «хорошие по башу», типа TLCL
The.Linux.Command.Line.2012.William.E.Shotts.Jr.A.Complete.Introduction.ePub
https://sourceforge.net/projects/linuxcommand/files/TLCL/16.07/TLCL-16.07.pdf/download
но на память ни одной по «продуктивному башу» не помню.
И этот факт — ещё одно подтверждение того,
инструментарий поменялся (с 1995),
Ansible действительно проще
1) во вхождении (старте)
2) в поддержке/использовании
3)
это не более «модный», а более эффективный инструмент на сегодня.
Ваши (и мои тоже) знания действительно устарели
и unix-shell-scripting-background может как помогать,
так и мешать
например, я работал с bash-профи, который использовал
Puppet просто как средство доставки файлов .sh и .tgz
т.е. не в парадигме инструмента (bad practice, даже worse)
в его версиях скриптов невозможно было разобраться в принципе
— версионирования, тестирования и т.п. не было как такового
я их отличал только по MD5 hash-у,
что довольно тяжело при полутора тысячах узлов
человек выстроил инфраструктуру, замкнутую на него самого
— все окружающие страдали.
Все же я считаю, что шелл скрипты вы ругаете необоснованно, каждому инструменту свое место.
Вот, к примеру, задача из недавних.
Мне приходят холодные копии оракловых БД, моя задача — поднять пришедшую БД на сервере solaris на рамдисках заданного размера, проследить, чтобы размер табличных пространств был не менее указанного.
Если меньше — добить табличные пространства файлами, если файлы не помещаются на существующие рамдиски, насоздавать их еще и таки добить файлами на них.
Пересоздать транзакционные журналы в нужной конфигурации и поменять рад настроек в самой БД.
Автоматизация этой задачи — чуть более 300 строк шелл скрипта, который работает с любой БД, любой структуры.
Есть более удобное решение?
С книжкой знаком, благодарю.
shell script-ы вы ругаете необоснованно,
каждому инструменту свое место.
я ругаю не shell script-ы, а построение на них инфраструктуры.
Вот, к примеру, задача из недавних.
Вы спроектируете роли, задачи, состояния,
короче сделаете свой Ансибль
из
чуть более 300 строк шелл скрипта
а затем с вами что-то случится (найдёте более интересную и высокооплачиваемую работу)
и поддерживать ваш баш никто не сможет.
Он будет падать при любом изменении
и его выкинут, лишь бы не трогать.
Потому что трогать никто не захочет.
Свойства самого баша таковы, что любая программа,
состоящая из более, чем 10 строк,
становится абсолютно нечитаемой.
а если в .sh-скрипте из 30 строк кода нет 50 строк комментариев
— поддерживать такой код через месяц не сможете даже вы сами.
За 300 строчек я сразу увольняю.
Если сотрудник просит 2 недели на поиски работы
— он эти 2 недели переписывает свой bash в современный язык
и покрывает тестами вида
«произвольно выбираем случайный узел и гасим его».
Я однозначно согласен с вами про то что построение инфраструктуры на shell это дорога
в ад. Например в случае с init скриптами этим адом оказался systemd (шутка)
Но все же вы утрируете, 10 строк если не использовать монструозные конвееры это так себе скрипт. В него даже толком не запихать необходимых проверок.
Для себя я вполне допускаю использовать баш в следующих случаях
— стартап скрипты
— простейшие развертывания (удалить, разархивировать, скопировать)
— крон-джобы
Помним что случае разные бывают, не всегда инфраструктура полностью подконтрольна, не везде есть python и пр.
Вот например книга https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
В ней конечно речь идет о более «взрослых» языках, но многие идеи можно применять и для написания шелл скриптов.
Нечитабельную простыню можно и на «современном языке» писать с успехом.
Интересно, а сколько инженеро-часов было потрачено на создание мегакнопки? Ваяли в рабочее время или дома?
В ходе этого дела, я заскриптовал самые сложные части, чтобы упростить инструкции, жизнь себе и другим инженерам. Когда эти сложные части были заскриптованы — освободившееся благодаря им время частично тратил на улучшение, занимался проектом каждый рабочий день примерно часа по 2-3.
Ansible для настройки/деплоя
Jenkins — с правильным подходом позволяет и красивые выпадающие списки с версиями делать (nexus + parametrized build pluginx + groovy scriptler для вытаскивания доступных версий из нексуса)
Если сильно хочется, то есть еще Rundeck с плагинами, собсно оно для этого и предназначено: «Job Scheduler and Runbook Automation». А к Женькинсу есть плагин, который шедулит запуски в рандеке при успешном билде.
mail.ru вообще деплоится самописными скриптами на перле ;)
Прям классика из серии "Кратко о том, почему не стоит работать в ...".
К парням, которые пытались в силу знаний и умений, но хоть как-то решить текучку — вопросов нет: работает и ладно.
А вот чем занимались тим лид и пм по внутренним разработкам? Если их не было, то почему? В крупнейшем интеграторе не хватает специалистов по катанию серверов на оленях? А если были, то почему поделка на уровне фриланса за 3$/час?
Если бы я был TCO (тех.диром) в КРОКе — я бы ПОДЫСКИВАЛ ЗАМЕНУ
Денису, пишущему велосипеды на shell-скриптах в 2015 г.
Во-вторых директора интересуют факты работает/не работает и в срок/не в срок. Остальное детали.
описался
Во-вторых директора интересуют факты работает/не работает и в срок/не в срок.
вот поэтому у меня и ассоциируются
почти все интеграторы со словосочетанием
«безумно дорогое говно»
и всё что я эксплуатировал после КРОКа и ему подобных контор
было настолькор адски кривым и неюзабельным
(зачастую просто ничего не работало — банально пилили бабки),
что часто возникало желание найти авторов и…
На собеседовании я понял, что при достаточно высоких требованиях
рабочий день будет ненормированным
т.е. это было сознательное решение — выжать из человека всё
затем я уже столкнулся с проектами
и «внедрениями» этой компании
и чем дальше — тем хуже.
«Кнопка» — очередной минус,
гвоздь в крышку гроба
Изначально мой тезис был про то что CTO не увольняет конкретного исполнителя за говнокод на баше. Увольнять тут скорее нужно лида, архитектора, продакт оунера или кто там у них. В моей практике было полно случаев когда я говорил что так делать нельзя, это нарушение процесса, сейчас может ничего страшного не случится, но мы огребем в конце концов. Но мидл-менеджмент наваливался кучкой и приходилось делать.
Я не знаю, что там за баш скрипты в кроке, но это один геморрой. И дело не в том, что это нагромождение костылей, как правило, и т.п. Главная проблема таких скриптов в том, что они не идемпотентны.
В случае того же Ansible я уверен, что запуская плейбук, у меня никаких проблем не возникнет. Плюс, в таких системах уже куча готовых модулей, чтоб не велосипедить на баш скриптах это всё.
Как мои пальцы закровоточили, и я собрал велосипед для деплоя, который сэкономил больше 2 тысяч рабочих часов за проект