Загрузка некоторых специфических функций, но не всех разработанных функций от разработки до живого сервера

Question

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

Эти функции содержат некоторый код в общих файлах, т.е.Один PHP-файл содержит код для одной функции, а также еще одну функцию.

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

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

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

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

Я думаю, что система управления версиями может здесь помочь.

Как вы, ребята, справляетесь с этим?

Не могли бы выподелитесь идеями?

Answer 1

Ситуацией, которую вы описываете, невозможно разумно управлять. Я не верю, что было бы возможно заставить эту ситуацию работать, но реальный вопрос в том, зачем вам это нужно?

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

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

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

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

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

Answer 2

Решением может быть использование дешевых ветвлений версий, предоставляемых VCS, таких как Git или Mercurial. Проект будет состоять из множества ветвей функций, используемых для разработки упомянутых функций и построения ветвей, в которых будут объединены ветви функций и произойдет временное исправление. Когда ветка сборки готова к тестированию, она тестируется, исправляется, если необходимо, а затем ветка сборки отправляется на рабочую платформу. После проверки возможностей ветвь сборки может быть объединена с оставшимися ветвями, чтобы разрабатываемые ветви могли интегрировать «официальные» изменения. Подводя итог, приложение настраивается по необходимости из существующих ветвей функций.

Answer 3

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

Но у этого решения есть определенные затраты:

1. Время для разработки и тестирования механизма плагиновдля вашего приложения

2. Вам необходимо протестировать каждую конфигурацию плагина (набор включенных плагинов и их версии), которые будут развернуты.В противном случае существует риск того, что этот конкретный набор несовместим, и конечные пользователи будут первыми, кто увидит результирующий сбой, потерю данных или какой-либо другой ужас

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

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