Мне нужны идеи по сравнению нашего рабочего процесса с другими. У нас есть единственный разработчик, который работает над нашим маркетинговым сайтом, и она знает, как кодировать, и все (без опыта управления версиями, без командной строки ... ничего). В прошлом разработчик всегда редактировал все прямо на сервере с помощью Eclipse. Это означает, что если она что-то нащупала и сохранила, это было видно всему миру.
Итак, после десятков «неудач» мне было поручено создать новый рабочий процесс, более подходящий, чем просто редактирование файлов на реальном сервере. Вот что у меня есть ...
Сервер Subversion с маркетинговым репозиторием
«Производственная» виртуальная машина с основным маркетинговым сайтом, которая сейчас в сети.
«Промежуточная» виртуальная машина, которая позволяет ей видеть изменения в идентичной среде, прежде чем мы загрузим какие-либо изменения в «Производственную».
Скрипт, который позволяет ей синхронизировать последний тег SVN с любым из этих серверов.
Чтобы сохранить целостность этих двух серверов, я хотел бы создать третий сервер «песочницы». Это будет другая виртуальная машина, скопированная с промежуточного сервера. С этим сервером она может экспериментировать с кодом, пробовать новые вещи и не беспокоиться о создании промежуточного или производственного серверов FUBAR.
Когда я предложил этот план, я получил много ворчания и стенаний из разных сторон о том, сколько работы это создает для нее. Поток будет:
Edit Code in new branch > sync to SANDBOX. Repeat until satisfied. Merge changes to Trunk, create a new a tag from trunk and sync to STAGING. Do a QA check. If everything looks ok, sync to PRODUCTION. (Я очень открыт для новых идей для этого процесса)
Как и следовало ожидать от человека, который никогда в жизни не использовал систему управления версиями и привык редактировать файл, нажимая ctrl + s для сохранения, а затем обновляя браузер, это кошмар. Я бы хотел найти золотую середину, но мне трудно это сделать, если мы сохраним настройку Sandbox / Staging / Production.
Что сработало для вас, ребята?
Ваш план во многом верен.
Сделайте это обязательным для работы разработчика. Во что бы то ни стало, отправьте этого разработчика на обучение или в местную группу разработчиков, чтобы они его побили. Убедите в необходимости вашего общего босса. (Если необходимо, используйте сценарии «превратился в злоумышленник» или «что-то упустил» или простой сценарий «веб-сервер был взломан и испорчен». Хотя я бы рекомендовал git для любых новых проектов, размещенных на частном сервере. или платный аккаунт на github. ThinkLikeAGit, "Git - простое руководство" Роджера Дадлера, и "Git для детей от 4 лет и старше (прямо на видео) все классные.
Я предпочитаю, чтобы Master был основной ветвью разработки, промежуточной ветвью, развертываемой для тестирования, и производственной веткой (или тегами в промежуточной ветке с номерами версий в развернутых коммитах). Мне также нравится идея веток для функций. Спросите 100 разработчиков, как им нравится их система контроля версий, и вы получите около 65 ответов ...
Я категорически не люблю и не рекомендую Мастеру быть отделением "Производство". Одна ошибка новичков (которую делают ВСЕ) - это переход в неправильную ветку. Не позволяйте Production быть ветвью по умолчанию.
Да, это место, где разработчики могут сходить с ума. Делай что хочешь; это твой дом, песочница, да что угодно. Разработка должна происходить на локальной машине, но это среда, которая будет похожа на производственную, но с гибкостью, чтобы сойти с ума. Рекомендуется использовать виртуальную машину со снимками, сделанными в базовом состоянии (и при каждом обновлении Prod).
Когда разработчик доволен своим кодом, он развертывается на промежуточном сервере. Это сервер, который точно соответствует продукту, за исключением URL. (Ее код должен использовать относительные пути, а не фактическое название сайта.)
Вот что интересно: как только она убедится, что сайт готов к работе, она останавливается. Она не выполняет развертывание в Prod (пока). Сейчас происходит неизвестный процесс контроля качества. Кто-то, кто следит за ошибками (и кто имеет хотя бы общее представление о том, что должен делать этот новый код) просматривает сайт в Staging. (Вы, как создатель, не замечаете многих собственных ошибок, что лишает вас возможности проверять свою работу.) Они тестируют сайт, гарантируя, что проблемы, которые решаются, и что ничего нового не сломано.
Не могу не подчеркнуть: разработчик не занимается тестированием! Она должна убедиться, что на ее сайте нет очевидных неисправностей, прежде чем передать его QA, но она не утверждает его для производства. (Во-первых, она продемонстрировала непонимание передового опыта, а ошибки показали, что передовой опыт существует по уважительным причинам.)
На карту поставлена профессиональная репутация человека, который занимается контролем качества; Если ошибка доводится до Prod, то это произошло с его одобрения.
Если QA находит ошибки, они передаются разработчику для исправления. Процесс начинается заново, завершается проверка качества и согласование.
Лично я фанат разработчиков, выполняющих собственное развертывание. Они получают мгновенную обратную связь, зная, что задача завершена, и, не заставляя кого-либо выполнять развертывание, они чувствуют большую ответственность, если что-то пойдет не так. (Сказать «это работает на моей машине» должно быть уголовным преступлением.)
Самая важная часть - это то, что находится в репо, развертывается. Нет никаких «разовых» изменений в ковбойском кодировании.
После завершения проверки качества код можно, наконец, отправить в Prod. Вы и ваша организация решаете, кто будет выполнять развертывание; это может быть кодировщик или специалист по контролю качества. Если развертывание не выполняется полностью, оно возвращается разработчику.
То, как сейчас идут дела, явно не работает. Постарайтесь сделать что-то вроде этой обязательной политики компании (если вы, конечно, согласны с ней) и сделайте занятость условием ее соблюдения. Это может сделать больше шагов для вашего бедного разработчика, но для компании это меньше работы, особенно в наличии ошибок. Не говоря уже о подстраховке от заведомо исправных состояний вашего кода, которые находятся вне рабочего веб-сервера.
Я не знаю, что вы делаете для развертывания, но они должны быть одношаговыми или бесшаговыми.
Примером одноэтапного развертывания является сценарий, который вы запускаете на сервере Prod или против него (и должны быть также и промежуточные серверы, и Devl тоже), который извлекает соответствующую ветку из вашего репозитория и перезапускает необходимые веб-службы. .
Примером бесшагового развертывания является cron, который отслеживает соответствующую ветвь и автоматически обновляет код при обновлении ветки.
Если бы ей пришлось работать непосредственно на сервере SANDBOX, но сделать сам корень документа рабочей копией «маркетингового» репозитория, то единственное, о чем ей нужно было бы беспокоиться во время цикла редактирования-обновления, - это периодические проверки. Скоро ей будет интересно, как она обошлась без ВК. Значение тегов и веток может быть труднее передать. Сделайте развертывание в STAGING и PRODUCTION как можно проще, написав для них сценарии.
Частично здесь не хватает в основном того, как управлять выпуском и выполнять его, и / или формального механизма контроля изменений. Я не предлагаю создать реальное приложение, но должен быть процесс, который включает:
В идеале, кто-то помимо разработчика или лица, выполняющего изменение, должен выполнять проверку, а также документ или контрольный список, описывающий проверку.
Временное окно оговаривается заранее, что обычно исключает возможность делать что-либо в явно неподходящее время. (Кто продвигает код по пятницам?)
Я буду осторожен, чтобы не мешать процессу. Если они хотят продвигать код каждый день, система не должна быть препятствием для их выполнения.