Ограждения проекта: среда подготовки
Эта серия кратких статей состоит из нескольких вещей, которые я узнал за последние несколько лет работы над проектами в той области, в которой мы (при условии, что вы читаете это из той же части отрасли, что и я 🙂) Работа.
Если вы только что наткнулись на это, серия охватывает некоторые факторы, которые важны для проекта :
- Не должно быть «дизайна комитетом». “
- Никто другой, кроме основной команды разработчиков, не должен иметь возможности обеспечивать разработку, подготовку и производство.
- Никто не должен иметь возможности писать для производства, кроме команды разработчиков (и даже тогда должен быть процесс развертывания).
Мне не очень нравится создавать такие жесткие и быстрые правила именно потому, что со временем все меняется либо по необходимости, либо по мере накопления опыта. Вот почему я люблю «руководящие принципы».
Но на момент написания этой статьи я вижу, как разыгрываются такие вещи.
Предоставление сред
За последние несколько лет мы добились значительного прогресса в том, насколько быстро мы можем предоставлять наши системы, чтобы они все отражали друг друга (или в целом). Это включает в себя наши блоки разработки, то, как наши локальные машины отражают постановку, и то, как постановка отражает производство.
Предоставление новой среды, более или менее. Ролл с ним.
То есть, если это «работает на моей машине», должно быть правдой. Это не оправдание невозможности воспроизвести ошибку.
И когда это правда, это, вероятно, будет правдой на других машинах, на постановке и в производстве. И это приятно, правда? Я имею в виду, мы раскручиваем наши коробки, развертываем наши скрипты или делаем то, что мы делаем, а затем у нас есть необходимые настройки.
Так что же означает подготовка сред? Это зависит от того, какую среду вы имеете в виду.
Как это выглядит на самом деле?
Если вы работаете в WordPress, что я предполагаю, если вы читаете это, то предполагается, что вы используете как минимум веб-сервер, базу данных и PHP.
Среда разработки может выглядеть следующим образом:
- Апач Nginx, _
- MySQL, который является наиболее распространенным,
- Минимум PHP 5.2.4 (рекомендуется PHP 7.1),
- Или что-то сопоставимое.
Вы также можете использовать что-то вроде Laravel Valet или что-то вроде VVV. Все зависит от характера вашей работы.
Кроме того, в зависимости от характера вашего бизнеса вам может быть назначена интегрированная среда разработки (IDE) вместе с различными файлами конфигурации для обеспечения соблюдения определенных правил.
А остальные среды?
По-прежнему:
- разработка относится к настройке на вашем локальном компьютере,
- этап относится к области, в которой вы и заинтересованные стороны можете протестировать,
- а производство — это место, где находится приложение.
Но это также выглядит по-разному в зависимости от того, где вы работаете, как организована ваша работа и так далее. Дело не столько в том, как это используется, сколько в том, что это используется.
Постановка
Обычно это предоставляется на сервере (или группе серверов в зависимости от размера проекта), на котором вы можете развернуть свой последний код для тестирования. Он может включать частичную функциональность, тестовые данные и только подмножество информации из производственной среды (если вы решите извлечь эту информацию, а именно базу данных, из производственной среды).
Это дает вам и другим заинтересованным сторонам возможность просматривать, что происходит и как это будет работать в производственной среде, не беспокоясь об уничтожении чего-либо конфиденциального.
Код обычно развертывается из ветки, обычно master, из вашего репозитория Git (если это то, что вы используете). А такие инструменты, как DeployBot, CircleCI, Travis CI, GrumPHP, Behat и т. д ., также используются как для оценки качества кода, запуска любого автоматизированного тестирования, так и для окончательного развертывания кода.
В конце концов, каждая среда будет подготовлена таким образом, чтобы ее можно было быстро отразить на локальных компьютерах, промежуточных серверах и рабочих серверах. Кроме того, должно быть легко передавать и извлекать данные между ними, чтобы упростить работу с данными.
Производство
Наконец, производство — это реально работающий проект; Это означает, что сервер, приложение и база данных работают вместе и используются пользователями.
Это также означает, что код находится в стабильном месте. Скорее всего, существуют механизмы ведения журнала, которые будут уведомлять команду разработчиков о любых проблемах. В этой среде не должно происходить никаких изменений кода без предварительной проверки качества или подготовки.
И процессы на месте?
Итак, допустим, вы работаете с традиционной установкой, за неимением лучшего термина, когда все ваши развертывания выполняются через S/FTP в рабочей (или даже промежуточной) среде. Таким образом, пользователи могут извлекать файлы, вносить изменения и возвращать их обратно.
Это не хорошо.
Это означает, что любой, у кого есть учетные данные, может войти в систему, внести изменения и обойти систему управления версиями, непрерывную интеграцию, инструменты обеспечения качества и т. д., внося любые изменения, которые он хочет.
Это подрывает все процессы, поставленные на место. Это не только обходит стандартную процедуру (которая, конечно, существует не просто так), но и в конечном итоге приводит к нарушению кода, который разработчик или команда разработчиков имеет на своих машинах, главным образом потому, что то, что находится в производстве, больше не синхронизировано с репозиторий кода.
Кроме того, этот код может быть распределен по ветвям, которые еще предстоит объединить или развернуть. Это оставляет нам множество ситуаций, в которых разработчики и клиенты нарушили какую-то часть процесса сборки и, следовательно, весь проект.
Когда приходит время проверить производство, оно не синхронизировано с разработкой и промежуточным этапом, и никто не знает, почему. Когда приходит время развертывания, изменения перезаписываются, и ответственные лица теряют то, что, как они думали, они собирались увидеть.
Что делать команде?
Я не знаю, есть ли на этот вопрос один правильный ответ, но чем дольше я работаю в этой отрасли, тем больше я верю, что фирма – или фирмы, – ответственные за создание решения для клиента, должны контролировать процесс с самого начала. в конец.
- Дизайнеры несут ответственность за управление своими областями создания концепций, макетов, создание демонстрационных шаблонов и сбор отзывов,
- Руководители проектов несут ответственность за связь с отделами,
- Разработчики несут ответственность за реализацию решения и связывают работу дизайнеров с функциональной серверной частью,
- Клиент несет ответственность за рассмотрение изменений, предоставление отзывов и предоставление любой другой информации, необходимой для выполнения задачи.
Это означает, что когда дело доходит до настройки домена, хостинга, среды, контроля версий, процесса сборки и непрерывной интеграции, а также всего остального, о чем я не упомянул, полностью ложится на команду разработчиков.
Оставайтесь в окопах, держите цель (но помните об окружающих).
Проще говоря, это не входит в обязанности клиента и не должно им быть. Границы ответственности должны быть установлены, поддерживаться и соблюдаться всеми командами — не только разработчиками и клиентами, клиентами и дизайнерами, дизайнерами и разработчиками и так далее.
Что дальше?
В следующем посте я расскажу об обязанностях разработчиков (и других заинтересованных сторон) по поддержке среды для кода.
То есть, кто за что должен отвечать и кто имеет доступ для чтения и записи каких данных и как это может в конечном итоге повлиять на результат проекта.