Разработка с использованием предварительных инструментов разработчика

Question

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

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

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

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

Что ты думаешь? Стоит ли рисковать? Есть ли у вас опыт (хороший или плохой) подобных ситуаций?

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

[EDIT2] Спасибо Марджану за очень полезный ответ. Я надеялся получить больше ответов, поэтому я вознаграждаю за это.

Answer 1

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

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

Короче говоря: не только оценивайте продукт, но и оценивайте производителей.

Привет.

Answer 2

Это просто вопрос управления рисками.В открытом исходном коде альфа-релиз может означать много разных вещей.Вы должны быть готовы:

• обрабатывать изменения API;
• предоставлять исправления ошибок и обходные пути;
• тестировать стабильность, производительность и масштабируемость самостоятельно;
• отслеживайте изменения гораздо более тщательно и решайте, принимать ли их тогда;
• отслеживать прогресс, который они делают, и их реакцию на исправления / проблемы.

Вы используете непрерывную интеграцию, ты?

Answer 3

Это зависит.

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

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

Так что на вашей позиции я бы оценил качествоальфа-версия, а затем решить, может ли это пойти в производство.

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

Answer 4

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

Сказав это, естьодин из способов, как я вижу, можно попробовать и съесть свой торт и съесть его.

Если вы видите способ абстрагировать его, то есть изолировать свой собственный код от библиотеки, например, с помощью адаптеров или шаблонов фасадов., а затем идти вперед и использовать альфа для развития.Но заранее определите , какая самая последняя дата в соответствии с вашим графиком выпуска, что вы должны начать разработку своей собственной версии с тысячами строк за адаптером / фасадом.Если к тому времени альфа еще не превратилась в RC: улыбнись, потерпи и развивай свою собственную.