Comments 21
UFO just landed and posted this here
Водная вода.
Вот предположим у меня есть некое приложение, разработка и выкатка на бой которого не автоматизированы (какой-нибудь битрикс, например, чтобы не ходить далеко).
Тестовая среда (если есть) не идентичная боевой, т.к. находится даже на другой площадке (часто на локальной машине разработчика).
Тестирование зачастую не автоматизировано, т.к. большая часть изменений «визуальные» (поиграйте со шрифтами и вот это всё).
Даже предположим, есть система контроля версий (ну, в смысле все изменения на бою коммитятся в GIT).
Но нет автоматизированной публикации, т.к. она связана не только с файлами, но и с БД. Да и правки могут быть (и в файлах и в БД) как от разработчика, так и от каких-то контент-менеджеров, которые новости фигачат прямо на бой.
Вот как в этом всём видится DevOps?
Можно сколько угодно красивых терминов ввести, но вот описанный выше кошмар я не представляю как автоматизировать в красивую историю. А если всё это работает, то никто в здравом уме не выкинет его и не начнёт пилить с нуля на «правильном» фреймворке.
P.S. я не противник DevOps, я просто не понимаю что всё эта история значит конкретно (не говоря уже про то как в этому счастью прийти). А подобные статьи только водную воду добавляют…
Вот предположим у меня есть некое приложение, разработка и выкатка на бой которого не автоматизированы (какой-нибудь битрикс, например, чтобы не ходить далеко).
Тестовая среда (если есть) не идентичная боевой, т.к. находится даже на другой площадке (часто на локальной машине разработчика).
Тестирование зачастую не автоматизировано, т.к. большая часть изменений «визуальные» (поиграйте со шрифтами и вот это всё).
Даже предположим, есть система контроля версий (ну, в смысле все изменения на бою коммитятся в GIT).
Но нет автоматизированной публикации, т.к. она связана не только с файлами, но и с БД. Да и правки могут быть (и в файлах и в БД) как от разработчика, так и от каких-то контент-менеджеров, которые новости фигачат прямо на бой.
Вот как в этом всём видится DevOps?
Можно сколько угодно красивых терминов ввести, но вот описанный выше кошмар я не представляю как автоматизировать в красивую историю. А если всё это работает, то никто в здравом уме не выкинет его и не начнёт пилить с нуля на «правильном» фреймворке.
P.S. я не противник DevOps, я просто не понимаю что всё эта история значит конкретно (не говоря уже про то как в этому счастью прийти). А подобные статьи только водную воду добавляют…
как вижу это я, если что-то похожее на битрикс можно поставить не только лишь на проде, то делаем следующим образом, ставим копию на проде, копию на тестовом сервере, и копию на рабочем компьютере. в Git'е ветка master пушится в прод, test пушится в тестовый сервер, в dev сливается с других веток. кем то смотрится, тестируется, если есть тесты, мержится в test, соответственно если в github то через Actions через какой нибудь rsync заливается на тестовый сервер, на дашборд куда нибудь сообщается, что тестовый сервер готов к проверке. тестируется, если все нормально, мержится в мастер и тоже самое в отправляется прод. вот уже есть какой никакой pipeline, в него потихоньку встраивается тестирование. выделяются люди, если над проектом работает много людей, ответственных за проект, типа архитекторы. Они занимаются мержем из dev в test и master соответственно. У них свои метрики, KPI если хотите, они ответственны за код который выкатывают в прод. Если мало человек в проекте, ну как то настроить, чтобы друг друга проверяли, выделяли время и искали друг у друга ошибки. Т.е. должен быть кто-то со стороны, кто может сказать, что вот это у тебя завалит скорее всего вот то-то и то-то. Ну или тесты прогонять.
Сумбурно, но как то так я думаю.
Сумбурно, но как то так я думаю.
Поставить на 3 серверах веб приложение не проблема.
Поставить на всех 3 серверах GIT и настроить на общий remote тоже не проблема, как я описал выше.
Проблема в том, что такого рода приложения очень сильно завязаны на изменение контента. И контент часто меняется не только в БД, но и в файлах. И часто в одном и том же файле часть изменений вносится редактором контента, а часть разработчиком. Так что GIT становится только средством «слежения» за изменениями, но не средством их наката.
А ещё более-менее серьёзные изменения это не только файлы, но и изменения в БД, которые принято выполнять инструментами самого битрикса, т.е. админки. Нет скриптов для наката/отката таких правок.
Да, их можно для каждой конкретной задачи написать. Но это лишние трудозатраты и риск ошибки. А тут нам вроде бы автоматизацию обещают, да ещё повышение надёжности…
Так что можно называть всё это «пайплайн», «девопс», как угодно ещё. Суть остаётся прежней — нет описания ЧТО конкретно надо делать. И зачем.
Увы, ваш комментарий не ответил на на один из моих вопросов.
P.S. А это я ещё не говорю про 1С. Там у ребят, как мне кажется, ещё веселее…
Поставить на всех 3 серверах GIT и настроить на общий remote тоже не проблема, как я описал выше.
Проблема в том, что такого рода приложения очень сильно завязаны на изменение контента. И контент часто меняется не только в БД, но и в файлах. И часто в одном и том же файле часть изменений вносится редактором контента, а часть разработчиком. Так что GIT становится только средством «слежения» за изменениями, но не средством их наката.
А ещё более-менее серьёзные изменения это не только файлы, но и изменения в БД, которые принято выполнять инструментами самого битрикса, т.е. админки. Нет скриптов для наката/отката таких правок.
Да, их можно для каждой конкретной задачи написать. Но это лишние трудозатраты и риск ошибки. А тут нам вроде бы автоматизацию обещают, да ещё повышение надёжности…
Так что можно называть всё это «пайплайн», «девопс», как угодно ещё. Суть остаётся прежней — нет описания ЧТО конкретно надо делать. И зачем.
Увы, ваш комментарий не ответил на на один из моих вопросов.
P.S. А это я ещё не говорю про 1С. Там у ребят, как мне кажется, ещё веселее…
Суть остаётся прежней — нет описания ЧТО конкретно надо делать. И зачем.
Я тут ниже упомянул «технологов».
Их работа заключалась, в частности, в том, что бы составлять карты технологического процесса -т.е. расписывать процесс выполнения всех действий, разбитый на элементарные операции.
Так, что бы каждый, кто умеет читать — понимал, какие действия и в какой последовательности необходимо выполнять (и какой инструмент при этом использовать)
Причем было неважно — серийное это производство или нет — если процесс был достаточно сложным — карты заполняли и для единичного производства.
Но это лишние трудозатраты и риск ошибки.
Это далеко не лишние трудозатраты.
ну, если хотеть начитать двигаться к правильным процессам, то так или иначе надо что-то менять. Менять плохие практики на хорошие.
С базой данных так или иначе деплой через Git не сделаешь. Но и меняются данные, так чтобы ничего не сломалось. Т.е. эволюционно. Наращивая функционал. Т.е. база данных правится, и потом уже накатывается код, который обрабатывает новый функционал. Так вот, изменения в коде заворачивать на Git, да не так удобно, как заливать через FTP. Ну можно сократить до 2 серверов, все равно же не на продакте сразу все изменения делаете.
Потом, на сервера git ставить не надо. github actions или gitlab pipeline это такие штуки, которые видят что, что-то запушилось в master или другую ветку, это как настроить, и поднимают docker, в нем если надо проверяют, делают какую то рутину, и заливают на сервер данные как это сделали бы Вы сами, хоть через FTP хоть через rsync. Как Вам уже нравится.
Но да, Git в первую очередь тут является средством слежения за изменениями. Вы правы. Потому что если на проекте работаешь не один, где то кто-то внес какие то изменения, не отразил в документации или еще что, и все. А тут мы можем посмотреть, процесс изменения зависимых файлов. как и что в них правилось.
И еще, меняться очень сложно, меняться очень больно. Но если Вы понимаете что живете и работаете в кошмаре, что что-то не так, надо что-то делать. Либо не делать. До какого нибудь глобального факапа. Если все всех устраивает, то и менять ничего не надо, работает не трогай. Но если все таки кажется что, что-то не так, то маленькими шажками, надо двигаться к свету.
С базой данных так или иначе деплой через Git не сделаешь. Но и меняются данные, так чтобы ничего не сломалось. Т.е. эволюционно. Наращивая функционал. Т.е. база данных правится, и потом уже накатывается код, который обрабатывает новый функционал. Так вот, изменения в коде заворачивать на Git, да не так удобно, как заливать через FTP. Ну можно сократить до 2 серверов, все равно же не на продакте сразу все изменения делаете.
Потом, на сервера git ставить не надо. github actions или gitlab pipeline это такие штуки, которые видят что, что-то запушилось в master или другую ветку, это как настроить, и поднимают docker, в нем если надо проверяют, делают какую то рутину, и заливают на сервер данные как это сделали бы Вы сами, хоть через FTP хоть через rsync. Как Вам уже нравится.
Но да, Git в первую очередь тут является средством слежения за изменениями. Вы правы. Потому что если на проекте работаешь не один, где то кто-то внес какие то изменения, не отразил в документации или еще что, и все. А тут мы можем посмотреть, процесс изменения зависимых файлов. как и что в них правилось.
И еще, меняться очень сложно, меняться очень больно. Но если Вы понимаете что живете и работаете в кошмаре, что что-то не так, надо что-то делать. Либо не делать. До какого нибудь глобального факапа. Если все всех устраивает, то и менять ничего не надо, работает не трогай. Но если все таки кажется что, что-то не так, то маленькими шажками, надо двигаться к свету.
Извините, ерунда какая-то. Да, я понимаю, вы за всё хорошее и против всего плохого, я тоже.
НО.
Я описал вполне конкретную ситуацию (и она не уникальна, для других продуктов тоже бывает схожая), когда красивыми словами не обойтись.
Нужна конкретика.
И эта конкретика должна как-то преодолевать ограничения заложенные продуктом.
Который, на секундочку, работает и приносит пользу. А перелом этих ограничений будет стоить Заказчику увеличения трудозатрат. В разы. Просто потому всё ВСЁ придётся писать с нуля самим.
А зачем? Какую задачу ваши «хорошие» практики решают, которую не решают описанные мною «плохие»?
Поверьте, мне тоже нравится сделать git push на локальной машине в github, а потом смотреть как на heroku пересобирается мой python пэт-проект. Зависимости там обновляет и всё такое. Но это совершенно разный масштаб бедствия и тут я сразу заложил эту возможность.
А вы всё талдычите «пайплайн», «докер», «делает рутину»… Слов красивых много, конкретики мало.
НО.
Я описал вполне конкретную ситуацию (и она не уникальна, для других продуктов тоже бывает схожая), когда красивыми словами не обойтись.
Нужна конкретика.
И эта конкретика должна как-то преодолевать ограничения заложенные продуктом.
Который, на секундочку, работает и приносит пользу. А перелом этих ограничений будет стоить Заказчику увеличения трудозатрат. В разы. Просто потому всё ВСЁ придётся писать с нуля самим.
А зачем? Какую задачу ваши «хорошие» практики решают, которую не решают описанные мною «плохие»?
Поверьте, мне тоже нравится сделать git push на локальной машине в github, а потом смотреть как на heroku пересобирается мой python пэт-проект. Зависимости там обновляет и всё такое. Но это совершенно разный масштаб бедствия и тут я сразу заложил эту возможность.
А вы всё талдычите «пайплайн», «докер», «делает рутину»… Слов красивых много, конкретики мало.
если честно ерунда какая то, я посмотрел Ваши публикации, примерно в общем описал точно такой же процесс из Вашей же публикации «Как я перестал беспокоиться и стал коммитить в GIT на большом 1С-Битрикс проекте» а Вы сейчас на меня злитесь, что я возможно Вам не даю четкие шаги, как все надо делать, а талдычу красивыми словами. В каком месте сломалась логика нашей беседы?
Логика моих сообщений в том, что те практики, что я описал были внедрены на очень старом и довольно большом проекте с кучей костылей и правок ядра.
Этот процесс не претендовал тогда и не претендует сейчас на звание DevOps.
Этот процесс не автоматизирует накат полностью, в нём нет тестов (кроме как «глазками»). Это именно контроль целостности файлов и небольшая страховка от того чтобы при накате разработчик «не забыл» пару файлов (хотя тоже не факт что рабочая, т.к. накат обычно затрагивал несколько репозиториев).
Я тогда писал о том как на грёбаном битриксе хоть что-то подвести под git.
А DevOps и его адепты обещают золотые горы и молочные реки, но при этом только сыплют кучами непонятных терминов, но не дают никакой конкретики как быть с вот такими проблемными кейсами.
И повторюсь, это ещё не самая жесть. 1С, как мне помнится, ещё веселее.
Этот процесс не претендовал тогда и не претендует сейчас на звание DevOps.
Этот процесс не автоматизирует накат полностью, в нём нет тестов (кроме как «глазками»). Это именно контроль целостности файлов и небольшая страховка от того чтобы при накате разработчик «не забыл» пару файлов (хотя тоже не факт что рабочая, т.к. накат обычно затрагивал несколько репозиториев).
Я тогда писал о том как на грёбаном битриксе хоть что-то подвести под git.
А DevOps и его адепты обещают золотые горы и молочные реки, но при этом только сыплют кучами непонятных терминов, но не дают никакой конкретики как быть с вот такими проблемными кейсами.
И повторюсь, это ещё не самая жесть. 1С, как мне помнится, ещё веселее.
во :) теперь я Вашу попаболь понял. Просто на самом деле, нет единого какого то стандарта, есть общие принципы, а вариантов то много. Так же степень devops'а может быть разной, т.е. автоматизировать какой то процесс, или вообще все процессы. Это только методики и рекомендации, как правильно. А как использовать, что применять, все зависит от предметной области. Возможно то что Вы описали и нельзя нормально настроить, в силу специфических каких то причин.
Ну просто например создавать какой то относительно большой командой Java десктопное приложение, и скажем обычный сайтик, и т.д. это все разные процессы. Нельзя все под одну гребенку. Поэтому я и говорю, если чувствуете что что-то не то, меняйте, адаптируйте, автоматизируйте. Чтобы как можно меньше была зависимость от конкретного человека, как можно меньше ручного труда нужно было делать в процессе изменения сайта и т.п.
Ну просто например создавать какой то относительно большой командой Java десктопное приложение, и скажем обычный сайтик, и т.д. это все разные процессы. Нельзя все под одну гребенку. Поэтому я и говорю, если чувствуете что что-то не то, меняйте, адаптируйте, автоматизируйте. Чтобы как можно меньше была зависимость от конкретного человека, как можно меньше ручного труда нужно было делать в процессе изменения сайта и т.п.
Вот в том и беда, что сколько я статей, методик и рекомендаций пока ни читаю, нигде нет конкретики (очень редко встречаются описания более-менее подробные с конфигами но, естественно, не под мои среды и приложения).
А на работе уже навис DevSecOps. там огромные простыни текста, которые тоже не содержат ничего полезного, как и эта статья. А он принудительно обязателен для всех.
А умные слова и вода, как из этой статьи… Они бесполезны.
А на работе уже навис DevSecOps. там огромные простыни текста, которые тоже не содержат ничего полезного, как и эта статья. А он принудительно обязателен для всех.
А умные слова и вода, как из этой статьи… Они бесполезны.
ну смотрите, если у организации есть бюджет и потребность, лучше сходить на какие нибудь курсы по DevOps'у, во первых они шире откроют глаза на понимание проблемы, во вторых Вы сможете помучать преподавателей собственными проектами, т.е. как сделать конкретно на примере вот этого, и уже будете разбирать свой кейс, Вам дадут направление куда идти, что читать, куда копать. И может быть, по результату что нибудь да получится. из того что могу вспомнить, не сочтите только за рекламу :) это rebrain, у них сильные девопсы, они ведут бесплатные вебинары, где очень много полезного и я их стараюсь не пропускать. канал в телеграме можете посмотреть называется DevOps by REBRAIN. Там прилетают ссылки на вебинары. На вебинарах Вы сможете узнать уже о подробностях обучения. Можете в Otus посмотреть, тоже по девопсу, я там обучался на другом курсе, мне понравилось. Но обучение не гарантирует конечно что у Вас все получится. Есть еще один вариант, это платные консультации со специалистами в этой области. Посмотреть на тех же преподавателей из этих курсов, связаться с ними по почте, договориться, и проконкультироваться от и до как вариант.
Какой смысл идти на курсы по DevOps'у, если там будут повторять ту же воду, что в статьях, но за деньги?
Какие основания считать, что там будет не вода?
Какие основания считать, что там будет не вода?
нет, гарантий я думаю тут никто не даст, просто может быть, если есть желание продвинуться в этой истории, то можно привести мысли и знания в порядок, и тогда в совокупности, у Вас появится какой то опыт, за ним и понимание как можно решить проблему именно в Вашем случае. Но по факту, может конечно статься так, что Вы зададите вопрос преподавателю, как сделать? Он посмотрит и скажет, тут ничего нельзя сделать.
Вода камень точит. В идеале должно совпадать и люди (видение) и выбранные технологии. В моей практике команды Dev и Ops начинали с чего-то малого, то есть пилили PoC на одном из окружений, стендов. Затем собирались вместе и на основе полученного опыта пилили шаблоны, скрипты автоматизации и тянули конвейер CI/CD дальше.
Что такое DevOps
Раньше этот процесс назывался «внедрение», а инженеры, которые им занимались де-факто, носили обобщающее название «технологи».
(КДПВ просто замечательная. Сохранил для себя)
Все правильно, но написано каким-то вымученным языком. Может, и сам DevOps такой же?
«между командами разработчиков и операционными командами для более быстрого развертывания кода в производственных средах»
Операционные команды это кто?
Производственные среды это что?
Вы на систему управления ядерными реакторами хотитие обновление 5 раз на дню накатывать? Остановите шарикм я сойду.
«Вместо того, чтобы выкатывать большое количество функций приложения одновременно, компании пытаются выяснить, смогут ли они развернуть небольшое количество функций для своих клиентов с помощью серии итераций релизов.»
Т.е превратить жизнь Юзеров в бесконечный кошмар.
«Организации используют DevOps для достижения таких уровней производительности, которые еще несколько лет назад были немыслимы. Они выполняют десятки, сотни и даже тысячи развертываний в день, обеспечивая при этом надежность, стабильность и безопасность мирового класса»
Я один подозреваю что что-то в этом не так? Что-то не здоровое?
«Чрезмерные времязатраты на тестирование, развертывание и проектирование вместо фокуса на создании основных бизнес-услуг»
Мне кажется я нашел ключевой принцип этого нового лохотрона. Нахрен тестирование. Юзер лучший тестер. А что бы он не возмущался убедить его что это теперь модно. В таком потоке фичь он скоро забудет что ему там реально было надо. И да, производственные среды это прсто конструктор катастроф.
В итоге девопс стал просто красивым названием для продвинутых админов, сколько бы там не кричали про философию и методологию
Девопс девопсу рознь в зависимости от потребностей заказчика (компании) и как-то описывать под общую структуру саму методологию сомнительная идея
Sign up to leave a comment.
Гайд по DevOps для начинающих