Ограждения проекта: запись в производство
В последних нескольких статьях я говорил о нескольких вещах (сохраненных для фактического написания для производства), которые помогают запустить успешный проект:
- Опасности в «дизайне комитетом »,
- Рекомендации по подготовке среды.
Последнее, что я хочу сказать об изучении, которое я получил до сих пор, — это о сохранении общеизвестных ключей от царства письма к производству и о том, почему это важно.
Написание для производства
Идея написания для производства может показаться наиболее догматичным ограждением из упомянутых, потому что обычно это нормально для тех, кто создает решение, и они знают все тонкости того, как оно работает.
Другие заинтересованные стороны, скорее всего, этого не сделают (но если они это сделают, и команда разработчиков не возражает против того, чтобы другие использовали контроль версий для решения этой проблемы, тогда действуйте).
На самом деле, у кого есть разрешение управлять этим материалом?
Помните, однако, как упоминалось ранее в этой серии статей, что способ развертывания наших проектов теперь изменился, так что мы часто имеем непрерывное развертывание и непрерывную интеграцию.
И часто эти службы подключаются к репозиторию исходного кода, такому как GitHub, и системе обмена сообщениями (которая, в свою очередь, может быть подключена к Slack, что я считаю полезным).
Чтобы люди в команде знали, что и когда было развернуто, и знали, как получить код (который находится в репозитории, а не загружать его через S/FTP), если это необходимо.
Когда требуется исправление, должна существовать процедура. Возможно, кто-то дежурит, и есть процесс, в котором используются ветвление, слияние, тегирование и семантическое управление версиями.
Как бы то ни было, дело не столько в том, как работает процесс; дело в том, что он на месте и ему следуют.
Конечно, все это делается не для того, чтобы усложнить разработку (хотя я понимаю, как это может показаться). Это наоборот. Это по разным причинам:
- поддерживать непрерывное развертывание, понимаете, непрерывное,
- иметь интегрированные тесты,
- постоянно измерять стандарты кодирования или качество кода,
- чтобы предотвратить ковбойское кодирование,
- и более.
Дело не столько в том, чтобы не пускать других людей, а в том, что если ответственность за размещение кода лежит на разработчиках, то должен ли кто-то еще иметь доступ для записи на сервер?
И в этом суть: если вы работаете в команде, где процессы, которые у вас есть, могут полностью подорвать работу, которую вы делаете, в любом случае, какова цель процесса?
Потому что в любой момент может прийти кто-то еще, и это будет игнорировать все, что вы сделали. Вы тогда, по крайней мере:
- застрял с необходимостью получать свои изменения, вероятно, через S/FTP,
- сравните его с помощью инструмента сравнения с веткой, над которой кто-то работает,
- внедрять изменения (пусть выяснять, почему они были сделаны),
- а затем вернуться к работе над требованиями.
Звучит лихорадочно, когда вы так говорите, но именно так и происходит.
Вынос
Итак, какова цель последних нескольких постов? Если бы мне пришлось резюмировать это как можно короче, это:
Когда дело доходит до проекта, знайте свои обязанности и не выходите за их пределы. В противном случае вы рискуете испортить все дело.
Это касается разработчиков, дизайнеров, клиентов, маркетологов, менеджеров проектов и т.д. Как обозначаются роли, не знаю большого значения (я имею в виду, обычно понятно, кто кем должен быть в ролях выше) но я имею в виду с точки зрения кто является фактическим ответственным лицом — владельцем проекта — для всего проекта.
Не будь таким.
И в зависимости от того, как пойдет все вышеперечисленное, проект может представлять собой относительно простой набор повседневной работы.
Насколько это возможно, разве мы не хотим получать удовольствие от того, что делаем?