Хорошие, простые причины наличия нескольких сред

На протяжении всей моей карьеры я работал в компаниях, в которых были разные среды для разных целей. У нас всегда было более или менее наше окружение рабочего стола, среда тестирования, среда QA, промежуточная среда и производственная среда. Это касается как серверов / приложений, так и любых источников данных, которые мы использовали.

Когда я начал работать в моей нынешней компании, я обнаружил, что 90% приложений либо разрабатывались в среде настольных компьютеров на основе производственных источников данных, либо разрабатывались непосредственно на рабочем сервере в зависимости от платформы. Это не было особенно удивительно, поскольку меня наняли, чтобы внести изменения, чтобы улучшить работу команды разработчиков, что было ясно из моего собеседования. Мы постепенно начали переворачивать философию, и довольно скоро большинство приложений можно было запускать как в настольной, тестовой, так и в производственной среде. Вскоре после этого постановка пришла.

Теперь большинство наших разработчиков видят преимущества этой методологии и бдительно отстаивают ее. Тем не менее, у нас есть ряд устаревших приложений, которые никогда не переносились. У нас также есть ряд старых программистов, которые считают это пустой тратой времени. К сожалению, мы получили услугу, но никогда не получали полную поддержку от руководства. Мы получили то, что, по нашему мнению, было обязательством существенно инвестировать в это около года назад, но ничего не материализовалось, несмотря на значительное планирование, которое мы вложили в него. Теперь мы находим, что нам нужно все больше и больше сред. Для настройки нам нужна помощь команд администрирования сервера / сети, а также участие заинтересованных сторон в бизнесе для поддержки цикла выпуска. Сейчас мы находимся в месте, где проект может функционировать, что разумные разработчики считают «нормальным»

Я хотел бы представить полный аргумент, но у руководства действительно нет времени и интереса выслушать меня, пока не возникнет критическая проблема. Я не могу сформулировать преимущества просто, потому что это всегда казалось мне второй натурой. Мне было интересно, есть ли какие-нибудь веские, простые, неопровержимые причины для разделения сред, из-за которых у менеджеров не хватает опыта разработки для поддержки этой идеи? , Есть ли хорошие ресурсы / литература по теме?

Ответ: деньги

Мне все равно, какова настоящая причина. Деньги ДОЛЖНЫ быть корнем всех ваших рассуждений, особенно когда имеешь дело с управлением.

Если бы мы оба сидели в комнате по 2 часа, у нас могло бы быть множество причин, по которым лучше иметь несколько окружений.

Вот проблема: если причины не основаны на деньгах, то ни одна из них не имеет значения .

Программисты не нанимаются, чтобы быть умными. Они не наняты, чтобы быть творческими. Они наняты, чтобы увеличить доход - либо зарабатывая деньги, либо экономя. Если вы не делаете ни одного из них, вам лучше собрать свое резюме.

Если посмотреть на это с этой точки зрения, ответ прост:

Наличие только одной среды увеличивает время простоя и приводит к потере прибыли. Множество сред позволяет нам защитить нашу прибыль, предоставляя нашим пользователям такой же надежный и надежный интерфейс, как и наша компания.

Повторяйте это каждый день.

Ниже есть несколько замечательных комментариев, которые добавляют реальную ценность этому ответу, поэтому я упомяну их:

• Карл Билефельдт отметил, что анализ затрат / выгод является важным фактором. Экономист может относиться к этому как к альтернативным издержкам, связанным с несколькими средами. Хотя это может быть удивительно слышать, есть сценарии, когда несколько сред не могут быть ответом! Если веб-сайт вашей компании является очень незначительным дополнением, то неожиданный простой может фактически стать более экономически эффективным способом ведения бизнеса. Это не похоже на положение, в котором вы находитесь, но стоит упомянуть.

• У BlairHippo было хорошее замечание, что вы можете смело показаться катастрофой (и если вы потеряете данные, это так!). Ответственность - отличный инструмент для убеждения менеджеров, но все же по той же причине - судебные процессы стоят дорого. Избежание их экономит деньги.

В качестве дополнения я нашел эту статью довольно хорошей. Он не дает прямого ответа на ваш вопрос, но позволяет вам понять, как программисты относятся к руководству, что, в свою очередь, приводит к этому ответу. Хорошо читать.

Единственная точка отказа

Если у вас нет среды разработки или промежуточной среды, у вас есть единая точка отказа для этих устаревших приложений. Руководство услышит вас, если вы опишете устаревшие приложения в этих терминах.

Вы должны быть в состоянии передать свое сообщение звуковыми байтами, которые имеют для них смысл. Уберите из разговора слово « программист » и замените его словом « менеджер ». Также представьте, что у вас есть 30-секундная поездка на лифте, чтобы получить свою точку зрения.

У меня была ситуация, когда моим боссом был пехотинец морской пехоты. Я продолжал говорить ему, что мне нужны программные инструменты и компьютерное обучение для моих морских пехотинцев, чтобы быть более продуктивным. Он не получил это. Однажды я наконец зашел в его кабинет и сказал ему, что дела идут хорошо.

Я сказал кое-что об этом ... «Если бы я сражался на войне, я бы использовал палки, камни и ветки деревьев. Мне нужны гранаты, базуки и пулеметы». Он получил сообщение.

Это на самом деле критично?

Я могу понять желание использовать отдельные среды. Неочевидный вопрос:

Действительно ли важно перенести устаревшую систему?

Я думаю, что большинство технически мыслящих людей склонны концентрироваться на академическом вопросе о том, какой путь лучше, что хорошо в академической среде. Хотя в бизнесе лучшее не всегда побеждает. Я не говорю, что это отрицательно, или начать пламенную войну. Я утверждаю очевидное или то, что должно быть очевидным для тех из нас, кто был в программном бизнесе в течение нескольких лет.

Все деловые решения обычно принимаются на основе предполагаемой стоимости / выгоды. Таким образом, вопрос, который вероятно задает бизнес:

Оправдывает ли стоимость дополнительных инвестиций в систему и разработку в унаследованном приложении преимущество по сравнению с вложением этих же инвестиций в другой проект / продукт?

У меня есть и до сих пор проводится регулярный анализ затрат и выгод, чтобы определить не только миграцию / переписывание программного обеспечения, но и ежедневные решения, которыми обычно руководствуется лидер. Я перешел на переписывание / миграцию старого программного обеспечения, потому что оно имело ограниченный срок службы и следовательно ценность.

Разделение Сред

В бизнес - причины для разделения сред.

• Меньший риск в выпусках и исправлениях ошибок. Докажите это числами. Сколько раз продукт выходил из строя и стоил клиенту дохода из-за плохой версии / ошибки.
• Меньший риск в развитии. Случайное сдувание БД разработчика отличается от случайного сдувания БД производства
• Способность четко разделять роли и доступ, т.е. лучшая безопасность ограничение количества пальцев в производстве пирога - это хорошо
• Возможность разделения сред, а также практики и процедуры, которые сопровождают этот стиль разработки, позволяют в будущем встраиваться в облачные системы.
• Разделение среды должно повысить эффективность репликационных сред, что может быть полезно при планировании, а также при динамическом масштабировании.

Похоже, у вас уже есть все "правильные" аргументы. Вместо этого вы испытываете «красную сельдь», если хотите. Или "погоня за морковкой"

у руководства действительно нет времени и интереса выслушать меня, пока не возникнет критическая проблема

Вот что я считаю реальной проблемой. По моему опыту, если у компании есть плохие методы разработки, как вы описали. Это не просто вопрос «мы не знали ничего лучше». Скорее, это сборник технических долгов, вызванных командой высшего руководства, которая не знает (заботится?) О проблемах, которые она представляет.

В таких случаях хороший бодрый разговор не собирается внезапно качать вещи в вашем направлении. Может быть, серьезная травма (сбой продукта, видимый клиенту и напрямую связанный с плохой практикой), но я уверен, что здравомыслящие технические специалисты еще до того, как вы попробовали поговорить.

Я предлагаю либо смириться с этим и принять вещи такими, какие они есть, либо искать новую должность.

Сколько групп людей планирует работать над приложением одновременно? Обычно я видел одну среду для каждой группы людей. Это разработчики (они получают среду DEV и среду интеграции DEV - некоторые скажут, что нет необходимости на 100%, я бы сказал, что это зависит от проекта), две среды тестирования (одна группа тестировщиков проводит очень подробное тестирование, другая для тестеры QA высокого уровня - обычно это реальные бизнес-пользователи, а не обученные тестеры). Также обычно есть изолированная среда тестирования производительности (так что вы можете тестировать огромные объемы данных, моделировать огромные объемы пользователей и т. Д.).

Почему все эти среды? Таким образом, разные группы могут тестировать разные функции, не наступая друг другу на пальцы. Если разработчики и тестировщики работают в одной и той же среде, это кошмар: тестировщик может открыть дефект в функции, которую разработчик каждую минуту активно меняет. Если есть два уровня тестирования, они могут сосредоточиться на различных действиях и не беспокоиться о том, чтобы испортить данные друг друга. Наличие изолированной рабочей среды позволяет запускать тесты, которые могут повесить машину, но если она изолирована, другие тестеры не будут затронуты.

Когда слишком много людей пытаются сделать слишком много разных вещей в одной и той же среде, вы теряете много времени, поскольку одна группа ожидает завершения теста другой группы, чтобы они могли выполнить свое. И это напрасно тратит время, а потраченное время может привести к потере денег, которые, как указал Stargazer712, могут стать самым сильным ударом.

Другой причиной (не такой распространенной) являются данные: если ваше приложение имеет конфиденциальные личные данные или данные кредитных карт, вы обычно не можете поместить их в тестовые среды, и обычно есть требования маскировки для всего, кроме сред QA и Production.

Вы, кажется, приложили немало усилий, чтобы добиться культурных изменений на вашем рабочем месте. Это большое достижение, так как перемены трудны в лучшие времена, но культурные перемены связаны не только с изменением сознания людей, но и с изменением привычек, устранением предрассудков и, в конечном счете, открытием потенциально закрытых умов для больших возможностей. Таким образом, вопрос, который нужно задать себе в этот момент: «Что я пропустил?». Простой ответ заключается в том, что вы, возможно, не полностью связаны с управлением.

Получить контроль от руководства легко, но еще сложнее получить признание. Независимо от аргументов о деньгах и т. Д., Реальность такова, что вы должны иметь возможность влиять на взгляд руководства на приоритет. У вашего менеджера будет бюджет, и он захочет показать, что бюджет был применен разумно и в соответствии с ценностями и приоритетами компании. Некоторые из этих приоритетов будут фискальными, а другие будут направлены на удовлетворение других потребностей. В некоторых случаях это может означать смазывание ладоней других менеджеров, чтобы получить повышение, которого всегда хотел ваш начальник. Однако в большинстве случаев речь идет о поиске путей расширения бизнеса или улучшения отношений с партнерами и клиентами. Если вы не можете изложить свои доводы в этих терминах, вы сможете зайти так далеко, пока не окажетесь в тупике.

Мое предложение состоит в том, чтобы попытаться обосновать продуктивность и то, как это влияет на бюджет, как предлагали другие, а также обосновать приоритеты вашей компании и то, как ваша производительность может напрямую влиять на отношения компании с другими компаниями.

Вот один из них: тестируемость.

Наличие среды тестирования дает вам свободу выполнять тесты в базе данных, которые было бы нежелательно выполнять в производственной среде.

Вы хотите изменить способ разработки программного обеспечения в вашей организации? Забудьте о «причинах» «делать вещи по-другому». Люди не меняют поведение из-за рациональных аргументов. Они меняются из-за психологических влияний на их привычки.

Итак, куда я иду с этим?

Хотя иногда вы можете успешно изменить поведение организации с помощью аргументации, есть и другие тактики, которые работают лучше. Они включают:

• Массовая поддержка: найдите ОДНОГО другого «унаследованного» разработчика, который готов дать вам шанс. Партнер с ним и изменить, как все работает. Не объявляйте об изменении. Просто внесите изменения. Если кто-нибудь когда-нибудь спросит вас об этом, просто скажите: «О да, вот как мы делаем это сейчас».

• Взять на себя ответственность. Доброволец, чтобы обращаться с развертываниями для наследников. Действуй так, как будто тебе это нравится. Они могут быть счастливы снять с себя эту ответственность. Затем запустите его, как вы хотите.

• Вини правых людей за их ошибки. В следующий раз, когда ошибка устаревшего приложения будет введена в производство из-за вашего механизма развертывания каменного века, укажите на это. Сделайте это тонко ... Не по электронной почте. В следующий раз, когда вы встречаетесь с менеджером, просто упомяните пример причины, по которой развертывание было проблематичным. «Да, помните, как мы боролись в прошлую пятницу из-за ошибки Foo, которую Боб зарегистрировал на производстве? Да, это было потрачено впустую!»

• Сделать это легко сделать лучше. Посмотрите на iphone, например. На нем ОДНА кнопка. (Ну два). Это ОЧЕНЬ легко включить. Сделать развертывание в нескольких средах безумно глупым. Сделайте так, чтобы все менеджеры могли это сделать!

Это становится более серьезной проблемой, когда вы начинаете работать с взаимосвязанными или устаревшими системами, системами, от которых зависит работа и точность работы. Это важно, потому что между этапами должно быть разделение, это причина, по которой вы не пользуетесь PROD, потому что он может нанести ущерб в миллионы долларов за потерянное время .

Мы всегда делаем DEV -> QA -> PROD (иногда эти шаги разбиваются на более мелкие части) с идентичным оборудованием позади них. Текущие производственные данные всегда передаются из PROD в QA в DEV.

DEV: предназначен для разработки в качестве изолированной программной среды, где никогда не следует доверять вещам, которые повторяются и разбиваются с любыми данными в этой среде, и разработчики регулярно выискивают их, просто находя способы решения проблемы.

QA: Как только ваши разработчики будут удовлетворены модульным тестированием, настало время, чтобы тестовая группа увидела его. Они запускают тестовые случаи, тестирование производительности и находят ошибки. Эти ошибки / улучшения возвращаются в DEV, и цикл продолжается, пока все не будут довольны.

PROD: Как только вы дойдете до этого этапа, вы должны быть уверены, что код работает в сочетании с текущими данными, и ваша группа QA / бизнес-пользователи довольны реализацией. Если вы все сделали правильно, вы просто сможете обновить код и покончить с этим.

Точно так же, как вы никогда бы не выпустили непроверенный продукт для клиентов, вы никогда не должны выпускать непроверенный код в производственную среду.

Если компания не желает тратить время на то, чтобы сделать это должным образом, она окупит стоимость аварийного обслуживания и ошибок в 10 раз.

В качестве небольшого примера: у нас была одна компания, которая решила внести изменения в производственный отчет самостоятельно. Никто не знал, что это изменилось, пока мы не пришли к решению различных проблем год или два в будущем.

Когда мы указали на нарушение в отчете, лицо финансового директора побелело, оказалось, что они теряли ~ 250 000 долларов в квартал из-за того, что кто-то быстро менял ситуацию.

Происходит чаще, чем вы думаете, если вы не можете позволить себе сделать это правильно, тогда не делайте этого.

Управление имеет большое значение для успеха компаний-разработчиков программного обеспечения и программных продуктов, которые необходимы для создания этих сред. Давайте возьмем пример вашего проекта. Если ваше программное обеспечение разрабатывается в больших масштабах, то, если вы не управляете требованиями проекта, управлением процессом, сборками тестов и т. Д., Это может привести к провалу. так что управление проектом существует.

Я в некоторой степени согласен с @ Stargazer712 в том, что ваше утверждение указывает на денежные вопросы, но проверьте следующее утверждение, которое я получил из книги Марка Гамильтона «Разработка программного обеспечения: создание надежных систем» (Prentice Hall PTR, 1999, ISBN 0-13-081246- 3). Посмотрев все эти факторы; Мое мнение о вашем вопросе состоит в том, что Единая среда не дает вам сбережений, это будет длительный процесс для завершения проекта / программного обеспечения. Распределенные среды позволят сэкономить время и доходы, так как я узнал и понял из своего опыта, что произошло с начинающими компаниями-разработчиками программного обеспечения, с которых я начал свою карьеру.

Есть много статей, которые демонстрируют, что важно для успеха. Проверьте это. Организация для успешной разработки программного обеспечения.

Каждый человек в организации обладает определенными навыками, и эти навыки обычно сравниваются с формальными или неформальными показателями эффективности, что приводит к вознаграждениям (компенсациям) в качестве стимулов для будущей эффективности. Люди в организации устанавливают свою культуру - те модели поведения и ценности, которые обычно признаются принятыми.

Большой набор разработчиков программного обеспечения будет бороться и в конечном итоге не сможет достичь своих целей, если им придется тратить все свое время на борьбу с несоответствующей организационной структурой.

Многие стартапы начинают свою жизнь, когда в гараже работает не более пары разработчиков. На данный момент в истории компании не требуется много организационной структуры, но организационная структура все еще существует. Например, в 1977 году, когда Билл Гейтс и Пол Аллен основали свое партнерство и официально назвали его Microsoft, компания имела минимальную организационную структуру. Менее десятка сотрудников работали в первом офисе Microsoft в Альбукерке, штат Нью-Мексико, и все знали, кто за это отвечает. Никаких сложных организационных схем не требовалось, чтобы выяснить структуру отчетности каждого. В то же время все сотрудники знали свою роль в компании и то, что они пытались достичь. Это произошло потому, что любая организационная структура, которая была необходима, могла быть неофициально сообщена каждому из сотрудников.

Забудьте время, деньги, проверяемость, качество ... как насчет репутации .

веские, простые, неопровержимые причины разделения сред, из-за которых у менеджеров не хватает опыта разработки для поддержки этой идеи.

Uber недавно отправил на github код, содержащий пароли для их реальной среды , что позволяет «хакерам» загружать все свои данные о клиентах. Убер говорит, что это было брешь, все остальные говорят: «Не размещайте ключи своих замков в открытом доступе. Если их разработчики работали исключительно над средой разработки, они могли бы выпустить ключи своей среды разработки на github, но это полностью Безвредность. То, что производственные выпуски были выпущены, показывает, насколько плоха эта идея выполнения dev в производственной среде.

Просто напомните своему менеджеру о том, что ошибки случаются, поэтому способ не допустить, чтобы его вытащили перед генеральным директором, который готовит критику перед журналистами, и техническая публика посмеялась над этим, - предпринять простые, очевидные шаги, чтобы эти ошибки не были катастрофическими. из них.

Похоже, у вас есть много различных сред, и это стоит людям много времени, чтобы настроить "среду".

У вас должно быть наименьшее количество различных «сред», с которыми вы можете справиться, но у вас должно быть возможность клонировать множество копий по тем причинам, которые вы и компания хотите (используя «среду» для обозначения конфигурации системы)!

Оптимально единственные различия должны быть:

1. Размер (минимальный, рекомендуемый, самый большой поддерживаемый / протестированный против);
2. Постановка и производство не имеют инструментов разработки
3. Продукция защищена от случайного перезаписи данных
4. Вы можете очень легко загрузить демонстрационные, тестовые или [аномизированные] данные клиентов на серверы разработки или промежуточные серверы.

ЗАТЕМ, вопрос о том, сколько и какого рода тестирование должно быть выполнено, является оценкой риска / стоимости бизнеса и решается на уровне компании, потому что именно бизнес в целом пострадает, если значительные сбои попадут на ряд клиентов. ,

Позже Редактирование: Это побудило меня рационализировать мои соглашения об именах с моими веб-продуктами (спасибо за вопрос). Я выбрал четыре «среды» с разделением тестирования между qa (минимальный одноуровневый уровень только для тестирования функциональности) и промежуточным этапом (та же архитектура, что и для производства, для тестирования нагрузки / производительности / объема).

Единственным реальным отличием в подготовке является производственная / промежуточная установка БД в отдельную систему, которую я контролирую, в зависимости от того, в какие группы входят разные серверы. У qa / dev есть и веб-сервер, и роли db. Балансировка нагрузки осуществляется с помощью cloudflare.

У меня также есть переменная ENV_NO, которая передается в системы, поэтому я могу выбрать столько «qa» или «промежуточных» примеров, сколько захочу.

Итак, чтобы настроить вторую среду qa, включая мою последнюю резервную копию из живого, команды были бы:

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

Наконец, у меня есть один дополнительный (необязательный) сервер с именем «readonly» в качестве последней защитной сети перед тем, как взяться за дело. Он настроен как система qa, но резервное копирование и обновление последних ночей отключены (программное обеспечение также обновляется до прошлой ночи).

Он использует подход «Все яйца в другой корзине»: он предоставляется с другим местоположением / регистратором DNS, хостом DNS, провайдерами услуг хоста системы. Это предельная / последняя сеть безопасности, поэтому, если все загорелось, вы можете, по крайней мере, получить данные до прошлой ночи. Сценарии обеспечения изолируют разницу между разными поставщиками, поэтому 99% одинаковы, только флаг readonly. Балансировщик нагрузки Cloudflare перенаправит трафик на сайт только для чтения, если все работающие серверы выйдут из строя.

Когда дело доходит до внесения изменений, вам повезет, если кто-то просто послушает ваше профессиональное мнение и внесет предложенные изменения.

Исходя из моего опыта, каждый раз, когда мне приходилось вносить серьезные изменения, мне приходилось оправдывать это с точки зрения экономии, которую может сделать бизнес. Например, внедрить ReSharper в конвейер разработки было довольно легко, так как я мог сказать что-то в отрыве:

ReSharper стоит около 50 фунтов за разработчика. Средняя стоимость разработки в год составляет £ 40 тыс. ReSharper должен повысить производительность разработчиков как минимум на 20%, учитывая его полный потенциал. Скажем, разработчик тратит 75% своего времени на написание кода в IDE. 75% от 40 000 фунтов стерлингов - 30 000 фунтов стерлингов. 30 000 фунтов стерлингов в настоящее время являются издержками производительности разработчика. Дополнительный процент производительности (1%) в год стоит £ 300. Чтобы получить дополнительные 20% производительности, бизнес должен был бы потратить 6 тыс. Фунтов стерлингов.

Если вы хотите представить это на перспективу для бизнеса, вы можете сказать, что вы можете нанять кого-то другого и получить дополнительную 20% -ную производительность за £ 6 000, или вы можете получить тот же результат, потратив £ 50 на лицензию ReSharper. Как только цифры окажутся перед бизнесом, решение будет легко принять.

Теперь, что касается ваших вопросов с несколькими средами, все, что вам нужно сделать, - это найти способ подсчитать, сколько стоит бизнесу каждый год, чтобы иметь эти среды.

Вы можете попросить своих коллег-разработчиков следить за часами, затрачиваемыми каждую неделю на настройку приложений для разработки, развертывания и т. Д. Например, десять часов времени старшего разработчика могут стоить бизнесу £ 500. Это 10 часов, которые можно потратить на разработку или что-то гораздо более важное. Вы собираете цифры за некоторый период времени и предоставляете бизнесу ежегодные расходы.

Я лично ненавижу такую ​​политику, но она обычна, и мы должны с этим жить.