Вопрос

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

Это было полезно?

Решение

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

Будь то сценарий сборки или общедоступный веб-сервер.

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

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

Другие советы

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

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

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

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

Редактировать:Короткий ответ:Если вы "ставите на это ферму", то это "производство".

Это отличный вопрос - абсолютно важное различие, из-за которого у всех обычно возникают проблемы из-за недопонимания.Вопрос о том , что такое "производство" является подмножеством связанного с этим вопроса о том , что такое "Окружающая среда".

Итак , часть ответа заключается в том , что "производство" это ТОТ САМЫЙ "Окружающая среда" это самое важен и пользуется наибольшим доверием как "реальный"вещь.

Итак , теперь мы должны определить "Окружающая среда" (а затем вернуться к "производство"). Мы все еще далеки от удовлетворительного ответа.

Мы , программисты , используем термин "Окружающая среда" постоянно ссылаться на компьютерные системы, состоящие из аппаратного обеспечения, которое выполняет программное обеспечение.Это программное обеспечение - это код, который мы написали, плюс программное обеспечение, от которого оно зависит, которое было написано другими.Мы пишем наш код и интегрируем его с другим программным обеспечением, затем мы обычно запускаем интегрированное программное обеспечение через нарастающую серию тестов (модульные тесты, интеграционные тесты, функциональные тесты, приемочные тесты, регрессионные тесты и т.д.), Пока, наконец, не запустим интегрированное программное обеспечение в полном объеме, как оно и было задумано.

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

С другой стороны, возможно, вообще не будет никакой существенной автоматизации.Например, мы говорили о "производство" давным - давно , когда у нас была комната , полная людей, выполняющих ручной труд, который произведенный a продукт.Таким образом, в нашем "производство" "Окружающая среда".Существует также промежуточный этап, когда задействованная автоматизация не включает программное обеспечение, например, в случае, когда человек управляет ткацким станком для ткачества ткани.

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

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

Теперь мы коснулись всех важнейших элементов "Окружающая среда":

  • есть цель, есть intent, преследуемый
  • ан intent требуется интендант, поэтому должен быть sponsor (человек или группа, но не машина), который определяет intent
  • это intent преследуется с помощью различных processes которые выполняются различными actors
  • те actors это могут быть люди, это может быть программное обеспечение, выполняемое на оборудовании, или они это могут быть машины, не управляемые программным обеспечением, поэтому автоматизация может присутствовать, а может и не присутствовать

Теперь мы можем правильно и полностью определить наши первоначальные термины.

Ан environment состоит из всех processes и их actors это сотрудничать для достижения определенной intent от имени своей sponsor.Это означает программное обеспечение, выполняемое на аппаратном обеспечении, это означает машины, не управляемые программным обеспечением, и это означает людей, выполняющих свои различные обязанности.Это тот самый intent это в первую очередь определяет environment, а не его processes или его actors.

Более того...

Если в intent преследуемый в конкретном environment является ли sponsor's конечная цель, которая обычно включает в себя создание product или предоставление service в обмен на деньги, тогда мы ссылаемся на то, что environment как production.

Теперь мы можем пойти немного дальше.

Если в intent преследуемый в environment является ли проверка processes и их actors в рамках подготовки к production, мы называем это test environment.

Далее мы называем это integration environment если это тестирование включает в себя первоначальное объединение значимых личностей или групп processes и их actors.

Если эта подготовка включает в себя "программирование" человеческого actors для выполнения новых processes, или последующая проверка (оценка), тогда мы называем это training environment.

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

Ан environment может быть неправильно помечен именем, которое не соответствует его intent, например , когда training окружающая среда используется как test.

Ан environment может быть грубо использовано не по назначению, например, когда integration или training делается в production.

Ан environment может быть искажено, например, когда ключ processes или actors остаются неопознанными (например, при ручном согласовании или даже при полном игнорировании людей).

Ан environment может быть переназначен путем перепрофилирования его processes и actors к новому intent.Очень успешным приемом для некоторых организаций является регулярное "переворачивание" нескольких наборов actors (серверы, на которых размещено программное обеспечение) между production, test, training, и integration после каждого выпуска.

В большинстве случаев один actor (человек или аппаратное обеспечение) может выполнять несколько processes который может участвовать в нескольких environments.Например, на одном компьютерном сервере может размещаться программное обеспечение, выполняющее production транзакции, а также размещение другого программного обеспечения, которое выполняет test или training функции.

Обычно один экземпляр actor должен участвовать только в одном environment за раз.В очень редких случаях один actor может быть общим для всех environments если в intents являются взаимно совместимыми.В большинстве случаев очень неразумно пытаться таким образом поделиться, потому что intents на самом деле они не совместимы.Прекрасным примером является запуск test process на сервере, который также поддерживает production processes, приводящий к простоям , поскольку test привело к сбою всего сервера.

Следовательно, в intent из одного environment должно толковаться с очень широкой широтой, включать такие понятия, как доступность, надежность, Производительность, аварийное восстановление, точность, точность, повторяемость, долговечность, и т.д.Это означает, что actors и processes часто должно быть истолковано как включающее такие вещи, как обеспечивающий питание, охлаждение, резервные копии, и избыточность.

Наконец, обратите внимание, что ситуация может стать довольно сложной.Например, настольный компьютер (actor) может быть поручено командой разработчиков (sponsor) для размещения их системы управления версиями (process), на которые команда полагается при выполнении своих основных заданий (production).Тем не менее, ИТ-персонал рассматривает тот же самый настольный компьютер просто как рабочую станцию разработчика (development, не production) и относится к нему с презрением и беспечностью, когда у него возникает проблема с оборудованием.Но разработчики производят production код, так разве они также не являются частью production?Перспектива имеет значение.

Редактировать:Качество продукции

Надежная проверка (testing) методология должна брать упакованный код из development и прогоните его через серию tests (интеграция, TQA, функционал, регрессия, принятие и т.д.), Пока не выйдет другая сторона, "проштампованная" для production использовать.Однако это делает пакет production Качество, но не на самом деле production.Пакет становится только production когда a sponsor фактически развертывает его в environment с этим предельным уровнем intent.

Однако, если ваша организация просто производит этот пакет (его product) для потребления другими, то такое высвобождение максимально приближается к production поскольку эта организация будет испытывать в отношении этого product, поэтому принято растягивать срок production применять, а не разъяснять , что это production Качество.На самом деле, эта организация production окружающая среда состоит из actors и processes участвует в его усилиях по разработке / выпуску, которые приводят к тому, что product.

Я сказал, что это может стать довольно сложным...

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

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

Джи-Мэн

  • Производственное программное обеспечение может работать с необходимой рабочей нагрузкой без сбоев или ухудшения качества обслуживания
  • Программное обеспечение было успешно протестировано в различных производственных сценариях
  • Преобразование рабочего прототипа в производственное программное обеспечение, работающее на отказоустойчивой избыточной архитектуре, которое может работать в реальном бизнесе, т.е.производственная среда, требующая времени, рефакторинга кода и внимания к деталям
  • Производственный код имеет приемлемый уровень ремонтопригодности и достаточно хорошо прокомментирован
  • Руководство по документации объясняет функциональность, все функции и облегчает техническое обслуживание
  • Если производственное программное обеспечение является международной службой или приложением, оно должно быть локализовано
  • Производственный код используется конечными пользователями, часто заказчиками, на условиях, описанных в Соглашении об условиях предоставления услуг
  • Производственное программное обеспечение не обязательно означает надежное критически важное программное обеспечение
  • Программное обеспечение хорошо выполняет то, для чего оно было предназначено
  • Файлы журналов содержат точное описание показателей производительности во время выполнения и надежности программного обеспечения, а также отчеты, которые облегчают отладку и удобство обслуживания программного обеспечения

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

Простыми словами, "Производственный код, который находится в режиме реального времени и используется целевой аудиторией".

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

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

С точки зрения жизненного цикла выпуска, "производственная" сборка - это сборка, которая выпускается для широкой публики или клиентов.Это этап после предварительной альфа-версии, alpha, beta (функция завершена, код завершен и т.д.) и release candidate.Для продуктов в термоусадочной упаковке, которые не могут легко развертывать обновления, переход к стадии производства, скорее всего, подразумевает серию тестов и исправлений ошибок.

alt text

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top