Кто несет ответственность за развертывание?

Question

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

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

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

Что такое опыт других народов? Должна ли команда разработчиков выполнить развертывание или мы должны просто передать завершенное программное обеспечение в ПО и оказать поддержку?

Подытоживая

много больших ответов, спасибо. Вопрос может показаться, что я пытаюсь извинить работу или ответственность, может быть, я немного; o) Меня больше интересуют процессы других народов. Проблема, с которой мы сталкиваемся здесь, заключается в том, что если разработчик развертывает программное обеспечение, мы в конечном итоге обеспечиваем 24/7 поддержку производства для программного обеспечения. Нет проблем, кроме нас только двое. Поэтому, чтобы позволить нам вернуться к разработке программного обеспечения, а не оказывать поддержку все время, я подумал, что было бы полезно привлечь команду «ИТ» к процессу разработки. Надеюсь, это получит «бай-ин», а затем позволит им развернуть и обеспечить поддержку первого уровня. У нас также есть завод в Мексике, и его сложная задача для команды разработчиков состоит в том, чтобы пойти туда и развернуть там, для местной поддержки это имеет смысл, с рекомендациями/советами разработчиков.

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

Answer 1

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

Answer 2

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

Answer 3

Зависит от проекта и того, что означает «развертывание» для вас. Поскольку я являюсь веб-разработчиком, развертывая в основном .NET-приложения с базой данных Sql Server, я всегда предпочитаю, чтобы развертывание выполнялось менеджером выпуска или менеджером развертывания. Зачем? Поскольку разделение рабочих мест гарантирует, что проблемы пойманы, когда они должны быть.

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

Конечно, в реальном мире это не всегда происходит из-за кадровых вопросов, но это было бы моим идеалом.

Answer 4

Кажется довольно простым для меня, если не вы, то кто? Будет ли фактическая ответственность за развертывание упадет до какой-либо другой команды, прежде чем вы начнете использовать Scrum? Если нет, то я не понимаю, почему Scrum изменит это.

Answer 5

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

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

Answer 6

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

2. если нет никого, чтобы нести ответственность за развертывание и управление конфигурацией, то вы это ;-)

Answer 7

Я являюсь разработчиком mgr с ответственностью за несколько продуктов. У меня есть мои команды разработчиков, которые производят сборку артефактов развертывания, таких как .war-файлы, которые можно просто развернуть на веб-сервере Tomcat, используя его менеджерский интерфейс или API веб-сервиса. Конфигурация приложения полностью установлена ​​и автономна в файле .war. Следовательно, человек просто делает развертывание, чтобы просто взять его и «бросить», если можно так выразиться.

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

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

В нашей организации ответственность за развертывание также перекрывается с ответственностью за поддержку первого уровня.

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

Answer 8

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

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

Answer 9

Кому звонят в 3 часа, когда программное обеспечение не работает или система умерла? Если это команда разработчиков, то, во что бы то ни стало, рассчитывать на собственное развертывание (поскольку у вас есть производство).

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

Если ваш контроль производства слабее, чем затяните их. Книга, подобная «Visible Ops», является отличным руководством для получения предметов под соответствующим уровнем контроля в соответствующих руках.