Comments 67
Делал что-то похожее на менее масштабном проекте. Удалось обойтись без своих велосипедов, хватило функционала TeamCity, который и дёргал всю гирлянду скриптов или конкретные из них. Вы не думали о нём, к слову?
или rundeck
Да даже Дженкинс можно тот же было привинтить.
Поделитесь опытом — как, а, главное, зачем?
Т.е. на каждый мердж в мастер:
И это на каждый пуш в мастер, я правильно понимаю?
Т.е. на каждый мердж в мастер:
- 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, стейбл же собирался либо вручную, либо по воскресеньям в ночь на пнд. Деплой можно было к конкретно взятому билду подвесить автоматом после сборки, либо же выполнить вручную.
В общем, всё можно сделать достаточно гибко. Никакого оверхеда и сборки после каждого коммита не было. Что же касается самих скриптов — я предпочитал создавать темплейты из скрипта, распиленного на степы, и потом создавать из них конкретные билды, лишь подменяя параметры в зависимости от стенда. Единократно требовалось бросить ключи на тачку с агента, и после этого всё было в практически однокнопочном режиме.
К примеру, у меня была гора планов сборки приложения, в зависимости от конкретного объекта, в которую были вложены разные ветки (dev, stable, и так далее). Те, в свою очередь, могли собираться или по временным триггерам (те же ночники), так и после N коммитов, или же вовсе лишь вручную.
Персонально у меня автоматом, как правило, собирался только next-release, стейбл же собирался либо вручную, либо по воскресеньям в ночь на пнд. Деплой можно было к конкретно взятому билду подвесить автоматом после сборки, либо же выполнить вручную.
В общем, всё можно сделать достаточно гибко. Никакого оверхеда и сборки после каждого коммита не было. Что же касается самих скриптов — я предпочитал создавать темплейты из скрипта, распиленного на степы, и потом создавать из них конкретные билды, лишь подменяя параметры в зависимости от стенда. Единократно требовалось бросить ключи на тачку с агента, и после этого всё было в практически однокнопочном режиме.
Вот ДА!
Надо было сделать некий интерфейс для разрабов, чтобы те могли создавать и копировать схемы оракла из прода в дев. Чем писать свой велосипед — сделал несколько джобов, которые читали вводные данные и запускали скрипты.
Надо было сделать некий интерфейс для разрабов, чтобы те могли создавать и копировать схемы оракла из прода в дев. Чем писать свой велосипед — сделал несколько джобов, которые читали вводные данные и запускали скрипты.
Собственно, да. Таким же образом, учитывая то, что все тачки на объектах были типовыми, собранными из OVF-шаблонов, можно было организовать и работу с удалёнкой: к примеру, тостировщик мог не напрягаясь зайти в ТС, ткнуть одну кнопку, и стянуть на нужный стенд свежую оракловую базу (можно было взять как горячую, так и ночной бэкап) с определённого объекта, если он был заведён к нам по VPN.
Всё, полчаса-час ожидания — и можно сидеть и проверять зарепорченный баг. А я могу сходить попить чаю, вместо того, чтоб сидеть тридцать минут в консоли и стучать в клавиатуру, как заведённый щелкунчик.
Всё, полчаса-час ожидания — и можно сидеть и проверять зарепорченный баг. А я могу сходить попить чаю, вместо того, чтоб сидеть тридцать минут в консоли и стучать в клавиатуру, как заведённый щелкунчик.
UFO just landed and posted this here
А у ansible есть хорошая веб-морда?
Главный вопрос в этом.
Главный вопрос в этом.
UFO just landed and posted this here
Ansible Semaphore? Я, правда, всё равно по старинке все плейбуки в блокнотике пишу.
Ответил ниже на похожий вопрос.
А ссылка на github?
и всякие мелкие полезностиА есть где-то весь список забавных фразочек из шапки?
Вот, пожалуйста =)
Цитаты из Кнопки
- Глаз страуса больше, чем его мозг, %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".
Т.е. заведомо нанимали меньше народа,
чтобы каждый работал не только за себя,
но и за того парня.
Мы следим за тобой, юзернейм.
Лепра уже не та, %username%
UFO just landed and posted this here
Сильно зависит от workflow. Когда нужно готовить хост с нуля они подходят очень хорошо. Но если надо менять кирпичик в уже построеном доме, то все становится очень печально… Т.е. сделать можно, но никакой эстетики.
UFO just landed and posted this here
Текущая инфраструктура бывает разной. Когда для того чтобы задеплоить компонент нужно несколько других остановить, причем на разных хостах. Потом поднять это дело в нужной последовательности и с проверками. А еще неплохо как-нибудь совместимость версий компонентов отследить… Тут приходит боль :)
Мне понравилось такое на XL deploy делать, но он сильно платный.
Мне понравилось такое на XL deploy делать, но он сильно платный.
UFO just landed and posted this here
Совместимости читай зависимости. Если компонент А требует версию компонента Б, то не давать ставить А. Но это уже детали.
Мне уже стало интересно как у вас все реализовано :)
Вот смотрите есть у нас DB, backend, frontend. И они зависят друг от друга по нисходящей. Миграция DB ведет к рестарту backend, а затем frontend. Апдейт версии backend влечет рестарт frontend. Получаем у нас есть три возможных артифакта и 7 вариантов деплоя.
И как реализовать деплой не плодя плэйбук на каждый случай? Я представляю что это можно решить через группы. И/или расписать все шаги и на каждом шаге проверять условия. Но мне кажется, что поддержка такого будет не слаще чем скриптов. Помним что пример абстрактный, и компонентов у нас на самом деле несколько десятков.
Мне уже стало интересно как у вас все реализовано :)
Вот смотрите есть у нас DB, backend, frontend. И они зависят друг от друга по нисходящей. Миграция DB ведет к рестарту backend, а затем frontend. Апдейт версии backend влечет рестарт frontend. Получаем у нас есть три возможных артифакта и 7 вариантов деплоя.
И как реализовать деплой не плодя плэйбук на каждый случай? Я представляю что это можно решить через группы. И/или расписать все шаги и на каждом шаге проверять условия. Но мне кажется, что поддержка такого будет не слаще чем скриптов. Помним что пример абстрактный, и компонентов у нас на самом деле несколько десятков.
Да ну нет же! Не знаю как в чефе-паппете, но в Ансибле прицип «desired state», очень он хорошо меняет кирпичик, просто замечательно.
Да, наверняка можно было бы использовать эти инструменты. Но так получилось, что сначала мы подумали, что справимся своими силами, а одновременно с пониманием, что руками тут делать многовато, появлялись скрипты. В итоге, когда полностью осознали ситуацию, скрипты уже были готовы и работали.
UFO just landed and posted this here
В крайнем случае
для сценариев 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
Вот честно, — я бы избавился от такого Дениса
под любым предлогом!
Я был в конторах, где десятки таких «гениев»
годами (если не десятилетиями) копили
тонны такого говнокода и говноинфрастуктуры
и я бы не согласился разгребать ЭТО
ни за какие деньги
потому что здоровье дороже
и нервов не хватит.
Плохо что у нас такие КРОКи — «короли госзаказа»
у буржуев на западе
подобная контора (а у них там всё так)
дожила бы ровно до первого грамотного аудита.
для сценариев 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…
Про какую книжку, кстати, Вы говорите? Я любитель юниксов, командной строки и всего такого, много лет пользуюсь шеллом и довольно много материала изучил по этой теме.
Закрытый код == говно. В том числе и из-за невозможности оценить
(или «заценить», глянув беглым взглядом на количество «звёздочек»,
количество контрибуторов и дату коммита).
Сейчас для баша все «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-у,
что довольно тяжело при полутора тысячах узлов
человек выстроил инфраструктуру, замкнутую на него самого
— все окружающие страдали.
(или «заценить», глянув беглым взглядом на количество «звёздочек»,
количество контрибуторов и дату коммита).
Сейчас для баша все «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 строк шелл скрипта, который работает с любой БД, любой структуры.
Есть более удобное решение?
С книжкой знаком, благодарю.
Все же я считаю, что шелл скрипты вы ругаете необоснованно, каждому инструменту свое место.
Вот, к примеру, задача из недавних.
Мне приходят холодные копии оракловых БД, моя задача — поднять пришедшую БД на сервере solaris на рамдисках заданного размера, проследить, чтобы размер табличных пространств был не менее указанного.
Если меньше — добить табличные пространства файлами, если файлы не помещаются на существующие рамдиски, насоздавать их еще и таки добить файлами на них.
Пересоздать транзакционные журналы в нужной конфигурации и поменять рад настроек в самой БД.
Автоматизация этой задачи — чуть более 300 строк шелл скрипта, который работает с любой БД, любой структуры.
Есть более удобное решение?
С книжкой знаком, благодарю.
shell script-ы вы ругаете необоснованно,
каждому инструменту свое место.
я ругаю не shell script-ы, а построение на них инфраструктуры.
Вот, к примеру, задача из недавних.
Вы спроектируете роли, задачи, состояния,
короче сделаете свой Ансибль
из
чуть более 300 строк шелл скрипта
а затем с вами что-то случится (найдёте более интересную и высокооплачиваемую работу)
и поддерживать ваш баш никто не сможет.
Он будет падать при любом изменении
и его выкинут, лишь бы не трогать.
Потому что трогать никто не захочет.
Свойства самого баша таковы, что любая программа,
состоящая из более, чем 10 строк,
становится абсолютно нечитаемой.
а если в .sh-скрипте из 30 строк кода нет 50 строк комментариев
— поддерживать такой код через месяц не сможете даже вы сами.
За 300 строчек я сразу увольняю.
Если сотрудник просит 2 недели на поиски работы
— он эти 2 недели переписывает свой bash в современный язык
и покрывает тестами вида
«произвольно выбираем случайный узел и гасим его».
Вы, как я вижу, сильно пострадали от баша. Я тоже на самом деле :)
Я однозначно согласен с вами про то что построение инфраструктуры на shell это дорога
в ад. Например в случае с init скриптами этим адом оказался systemd (шутка)
Но все же вы утрируете, 10 строк если не использовать монструозные конвееры это так себе скрипт. В него даже толком не запихать необходимых проверок.
Для себя я вполне допускаю использовать баш в следующих случаях
— стартап скрипты
— простейшие развертывания (удалить, разархивировать, скопировать)
— крон-джобы
Помним что случае разные бывают, не всегда инфраструктура полностью подконтрольна, не везде есть python и пр.
Я однозначно согласен с вами про то что построение инфраструктуры на shell это дорога
в ад. Например в случае с init скриптами этим адом оказался systemd (шутка)
Но все же вы утрируете, 10 строк если не использовать монструозные конвееры это так себе скрипт. В него даже толком не запихать необходимых проверок.
Для себя я вполне допускаю использовать баш в следующих случаях
— стартап скрипты
— простейшие развертывания (удалить, разархивировать, скопировать)
— крон-джобы
Помним что случае разные бывают, не всегда инфраструктура полностью подконтрольна, не везде есть python и пр.
Простыню в 300 строк читать конечно невозможно. Но изливать простыню или нормально структурировать и заботиться о читабельности кода — это ведь выбор автора, а не «свойства баша». Баш предоставляет все средста для реализации обоих подходов.
Вот например книга https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
В ней конечно речь идет о более «взрослых» языках, но многие идеи можно применять и для написания шелл скриптов.
Нечитабельную простыню можно и на «современном языке» писать с успехом.
Вот например книга https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
В ней конечно речь идет о более «взрослых» языках, но многие идеи можно применять и для написания шелл скриптов.
Нечитабельную простыню можно и на «современном языке» писать с успехом.
Интересно, а сколько инженеро-часов было потрачено на создание мегакнопки? Ваяли в рабочее время или дома?
Сначала недели 2-3 почти только этим и занимался.Но тогда еще не было понятно, как собрать систему из кусков. Передо мной стояла задача пройти по всем командам разработчиков, который пишут свои куски, взять у них их часть системы и разобраться, как это все собирать вместе. Записать полученные знания в инструкции итд.
В ходе этого дела, я заскриптовал самые сложные части, чтобы упростить инструкции, жизнь себе и другим инженерам. Когда эти сложные части были заскриптованы — освободившееся благодаря им время частично тратил на улучшение, занимался проектом каждый рабочий день примерно часа по 2-3.
В ходе этого дела, я заскриптовал самые сложные части, чтобы упростить инструкции, жизнь себе и другим инженерам. Когда эти сложные части были заскриптованы — освободившееся благодаря им время частично тратил на улучшение, занимался проектом каждый рабочий день примерно часа по 2-3.
После слов которые звучали не очень «Разрабы пишут код» — перестал читать статью! Извините, так как сам разработчик.
у меня не пальцы, а глаза закровоточили…
Ansible для настройки/деплоя
Jenkins — с правильным подходом позволяет и красивые выпадающие списки с версиями делать (nexus + parametrized build pluginx + groovy scriptler для вытаскивания доступных версий из нексуса)
Если сильно хочется, то есть еще Rundeck с плагинами, собсно оно для этого и предназначено: «Job Scheduler and Runbook Automation». А к Женькинсу есть плагин, который шедулит запуски в рандеке при успешном билде.
mail.ru вообще деплоится самописными скриптами на перле ;)
Ansible для настройки/деплоя
Jenkins — с правильным подходом позволяет и красивые выпадающие списки с версиями делать (nexus + parametrized build pluginx + groovy scriptler для вытаскивания доступных версий из нексуса)
Если сильно хочется, то есть еще Rundeck с плагинами, собсно оно для этого и предназначено: «Job Scheduler and Runbook Automation». А к Женькинсу есть плагин, который шедулит запуски в рандеке при успешном билде.
mail.ru вообще деплоится самописными скриптами на перле ;)
Прям классика из серии "Кратко о том, почему не стоит работать в ...".
К парням, которые пытались в силу знаний и умений, но хоть как-то решить текучку — вопросов нет: работает и ладно.
А вот чем занимались тим лид и пм по внутренним разработкам? Если их не было, то почему? В крупнейшем интеграторе не хватает специалистов по катанию серверов на оленях? А если были, то почему поделка на уровне фриланса за 3$/час?
Если бы я был TCO (тех.диром) в КРОКе — я бы ПОДЫСКИВАЛ ЗАМЕНУ
Денису, пишущему велосипеды на shell-скриптах в 2015 г.
Во-первых CTO, а не TCO.
Во-вторых директора интересуют факты работает/не работает и в срок/не в срок. Остальное детали.
Во-вторых директора интересуют факты работает/не работает и в срок/не в срок. Остальное детали.
да, верно
описался
вот поэтому у меня и ассоциируются
почти все интеграторы со словосочетанием
«безумно дорогое говно»
и всё что я эксплуатировал после КРОКа и ему подобных контор
было настолькор адски кривым и неюзабельным
(зачастую просто ничего не работало — банально пилили бабки),
что часто возникало желание найти авторов и…
описался
Во-вторых директора интересуют факты работает/не работает и в срок/не в срок.
вот поэтому у меня и ассоциируются
почти все интеграторы со словосочетанием
«безумно дорогое говно»
и всё что я эксплуатировал после КРОКа и ему подобных контор
было настолькор адски кривым и неюзабельным
(зачастую просто ничего не работало — банально пилили бабки),
что часто возникало желание найти авторов и…
А вы к компании КРОК так плохо относились до собеседования или уже после так стали?
Я ничего не знал о компании КРОК до прихода туда.
На собеседовании я понял, что при достаточно высоких требованиях
рабочий день будет ненормированным
т.е. это было сознательное решение — выжать из человека всё
затем я уже столкнулся с проектами
и «внедрениями» этой компании
и чем дальше — тем хуже.
«Кнопка» — очередной минус,
гвоздь в крышку гроба
На собеседовании я понял, что при достаточно высоких требованиях
рабочий день будет ненормированным
т.е. это было сознательное решение — выжать из человека всё
затем я уже столкнулся с проектами
и «внедрениями» этой компании
и чем дальше — тем хуже.
«Кнопка» — очередной минус,
гвоздь в крышку гроба
Менеджеров, помимо раобтает/не работает, много чего еще интересовать должно — риски, например, в виде воспроизводимости результата после того как на месте Дениса окажется Петя, или вероятности найти такого Петю, который уже почти в 2017 году спит и видит как бы овладеть чужим велосипедом на shell-скриптах.
Вы со своей колокольни судите. Вы на такую позицию не пойдете, я на такую позицию не пойду. Но на самом деле найти человека на shell скриптинг проще чем готового ansible/chef/puppet специалиста. И стоить он будет дешевле.
Изначально мой тезис был про то что CTO не увольняет конкретного исполнителя за говнокод на баше. Увольнять тут скорее нужно лида, архитектора, продакт оунера или кто там у них. В моей практике было полно случаев когда я говорил что так делать нельзя, это нарушение процесса, сейчас может ничего страшного не случится, но мы огребем в конце концов. Но мидл-менеджмент наваливался кучкой и приходилось делать.
Изначально мой тезис был про то что CTO не увольняет конкретного исполнителя за говнокод на баше. Увольнять тут скорее нужно лида, архитектора, продакт оунера или кто там у них. В моей практике было полно случаев когда я говорил что так делать нельзя, это нарушение процесса, сейчас может ничего страшного не случится, но мы огребем в конце концов. Но мидл-менеджмент наваливался кучкой и приходилось делать.
Вообще-то нет. Директор на то и директор, что смотрит на месяца, а то и годы вперёд. Если директор смотрит на ежеминутные результаты и не заглядывает наперёд, то из такой компании лучше валить.
Я не знаю, что там за баш скрипты в кроке, но это один геморрой. И дело не в том, что это нагромождение костылей, как правило, и т.п. Главная проблема таких скриптов в том, что они не идемпотентны.
В случае того же Ansible я уверен, что запуская плейбук, у меня никаких проблем не возникнет. Плюс, в таких системах уже куча готовых модулей, чтоб не велосипедить на баш скриптах это всё.
Я не знаю, что там за баш скрипты в кроке, но это один геморрой. И дело не в том, что это нагромождение костылей, как правило, и т.п. Главная проблема таких скриптов в том, что они не идемпотентны.
В случае того же Ansible я уверен, что запуская плейбук, у меня никаких проблем не возникнет. Плюс, в таких системах уже куча готовых модулей, чтоб не велосипедить на баш скриптах это всё.
я понимаю, что задаю самый глупый вопрос, но кто такая Лера?
Sign up to leave a comment.
Как мои пальцы закровоточили, и я собрал велосипед для деплоя, который сэкономил больше 2 тысяч рабочих часов за проект