Comments 5
Основная мысль которую должны понимать современные компаний занимающиеся разроботкой ПО/Web-приложений/и пр. должна быть следующей:
процесс разработки тестирования и эксплуатации ПО неразрывен. Программисты, админы и тестировщики всегда должны быть одной командой. Не нужно никаких модных слов. Нужна хорошая командная работа и грамотный менеджмент без матоков и размахивания пренадлежностями, и тогда и только тогда на выходе будет получаться хороший программный продукт. Без должного отношения друг к другу и нормального отношения к задачам не будет хорошего результата. В общем разработка это сложный процесс который требует слаженности и ответственности и не более.
процесс разработки тестирования и эксплуатации ПО неразрывен. Программисты, админы и тестировщики всегда должны быть одной командой. Не нужно никаких модных слов. Нужна хорошая командная работа и грамотный менеджмент без матоков и размахивания пренадлежностями, и тогда и только тогда на выходе будет получаться хороший программный продукт. Без должного отношения друг к другу и нормального отношения к задачам не будет хорошего результата. В общем разработка это сложный процесс который требует слаженности и ответственности и не более.
Угу… А то как в некоторых конторах — все по agile, вокруг одни techlead да devops в casual, с важным видом попивающие свои smoothies, постоянные seminars & techdays, по выходных — посещение co-working, иногда даже с co-living. А на выходе через полгода проекта — the bolt…
Плюсануть не могу, но согласен, кто же будет спорить с тем, что дело должно быть впереди пустых деклараций.
Попробую аналогию. Тут сказано, что все должны дружить и нужен клевый менеджмент. Супер, а куда деть реальность? Предположим, что организация это как клетка: есть органеллы, что делают свою работу и есть оболочка через которую идет взаимодействие- менеджмент. Новые идеи, чтобы они проникли внутрь организации и были восприняты менеджментом приходится как ДНК вируса обрамлять в оболочку способную помочь в проникновении в клетку. В данной аналогии такой оболочкой служит «маркетинг». Как ни хотелось бы чтобы дримтим был, в реальности требуются капитальные усилия, чтобы люди купили простые и понятные идеи. А «маркетинг» способствует тому, что если поблизости окажется эффективный менеджер, то он не будет активно противодействовать, восприняв адаптированную идею.
Ну и разумеется, есть те кто за видимым фасадом прячут пустоту. Мое мнение, плевать на тех, кто декларирует, что он develop'ит по agile, deploy и Test у него по Devops, хотя организация лишь перевесила таблички и перепечатала визитки. Если то, что мы пишем, будут читать разумные люди и делать определенные выводы, значит написали не зря.
Попробую аналогию. Тут сказано, что все должны дружить и нужен клевый менеджмент. Супер, а куда деть реальность? Предположим, что организация это как клетка: есть органеллы, что делают свою работу и есть оболочка через которую идет взаимодействие- менеджмент. Новые идеи, чтобы они проникли внутрь организации и были восприняты менеджментом приходится как ДНК вируса обрамлять в оболочку способную помочь в проникновении в клетку. В данной аналогии такой оболочкой служит «маркетинг». Как ни хотелось бы чтобы дримтим был, в реальности требуются капитальные усилия, чтобы люди купили простые и понятные идеи. А «маркетинг» способствует тому, что если поблизости окажется эффективный менеджер, то он не будет активно противодействовать, восприняв адаптированную идею.
Ну и разумеется, есть те кто за видимым фасадом прячут пустоту. Мое мнение, плевать на тех, кто декларирует, что он develop'ит по agile, deploy и Test у него по Devops, хотя организация лишь перевесила таблички и перепечатала визитки. Если то, что мы пишем, будут читать разумные люди и делать определенные выводы, значит написали не зря.
Есть еще один подход: «мы тут в enterprise, нельзя делать плохо, надо делать хорошо и быстро, то что вы не успеваете по срокам — это недоработка менеджмента, да, нужно над этим работать (из уст руководителя отдела, он же ставит сроки), нужно… (длинная терада про то что МЫ не умеем ставить сроки)» а потом, пятница, вечер, подходят к devops и говорят — «нужно внедрить, знаем что не протестировано, значе что перед выходными, но сроки горят, нужно было вчера… » И тут в голове DevOps'a всплывает «у нас же enterprise» а по факту у нас «The Bolt»
«Основная преграда» между разработкой, включая анализ, постановку и тестирование, и эксплуатацией — это ошибки во внедряемых сервисах, на самом деле это не преграда, а простой конфликт интересов, устранить его невозможно, но можно уменьшить, и пути на мой взгляд всего два — снижать количество ошибок, и увеличивать скорость их устранения. Чем больше автоматизируется разработка, тем конечно меньше ошибок просачивается в эксплуатацию, и тем больше возможностей появляется для анализа слабых звеньев. Но при некачественной постановке или несоответствии квалификации разработчиков сложности задач никакой DevOps не превратит плохой проект в хороший, он только может поспособствовать превратить хороший проект в еще чуть более хороший.
Sign up to leave a comment.
DevOps — новый уровень взаимодействия групп разработки и эксплуатации