Ежедневная сборка по сравнению с нулевым дефектом
Да, это одно из преимуществ HTTP / 2 и теоретически позволяет вам сохранять разделение для пользователей HTTP / 1.1 и автоматически отменять разделение для пользователей HTTP / 2.
Реальность, как всегда, немного сложнее - в основном из-за проблем с реализацией и серверов, разрешающих разные IP-адреса, как вы заявляете. Этому сообщению в блоге уже несколько лет, но в нем описаны некоторые проблемы: https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/ . Возможно, это улучшилось с тех пор, но представьте, что проблемы все еще существуют. Также должны помочь новые функции, такие как ORIGIN frame , но пока они не получили широкой поддержки.
Я думаю, однако, стоит пересмотреть предположение, что шардинг на самом деле хорош для HTTP / 1.1. Затраты на настройку новых соединений (поиск DNS, настройка TCP, рукопожатие TLS и затем фактическая отправка HTTP-сообщений) не являются нематериальными, и исследования показали, что ограничение в 6 подключений для браузера действительно используется, не говоря уже о добавлении дополнительных при помощи шардинга. Конкатенация, спрайты и встраивание обычно являются гораздо лучшими вариантами, и они все еще могут использоваться для HTTP / 2. Попробуйте это на своем сайте, и мера - лучший способ убедиться в этом!
Кстати, именно по этим причинам (и безопасности) я менее заинтересован в использовании общих библиотек (например, jquery, bootstrap). ..etc.) из их CDN вместо локального размещения. По моему мнению, выигрыш в производительности пользователя, уже имеющего версию, которую использует ваш сайт, уже кешируется.
С учетом всего этого HTTP / 1.1 по-прежнему будет работать без закрытых доменов. Это может (возможно) быть медленнее, но это не сломается. Но большинство пользователей , скорее всего, используют HTTP / 2 , так стоит ли добавлять сложности для меньшинства пользователей? Разве это не способ постепенного улучшения вашего сайта для людей в современных браузерах (и поощрение тех, кто не обновляет)? Для более крупных сайтов (например, Google, Facebook ... и т. Д.) Меньшинство может по-прежнему представлять большое количество пользователей, и сложность того стоит (а у них есть ресурсы и опыт, чтобы с этим справиться), а для остальных из нас, мой Рекомендация состоит не в том, чтобы обновлять протоколы, такие как HTTP / 2, когда они становятся обычными (как это происходит сейчас!), а в том, чтобы снизить сложность.
11 ответов
Да, примите процесс разработки программного обеспечения. Там существует разнообразие, в котором я уверен, что больше чем один будет соответствовать Вашей команде. Даже тот, который не является идеальной парой, не намного лучше, чем никакой процесс вообще.
Поэтому, как моя компания идет о наличии ежедневных сборок и борьбе за нулевые дефекты? Мы выполняем наш набор тестов, прежде чем мы зарегистрируемся в нашем коде. Уникальная проблема для нас состоит в том, что полное выполнение нашего набора тестов принимает 72 часа, таким образом, мы выполняем ограниченный набор модульных тестов перед регистрацией в коде. Для наших ночных сборок мы запускаем ряд тестов, которые занимают приблизительно 8 часов для выполнения. Затем в выходные мы выполняем полный набор тестов. Каждый этап ловит все больше проблем, но более чем 90% пойманы с 5-минутными тестами разработчика и вероятно более чем 98% с ночными тестами. Это все еще предупреждает нас довольно рано к проблемам, прежде чем они будут выходить нашим клиентам и будут стоить много для фиксации.
Я пошел бы с @feverentcoder на аргументах CI. CI является Вашим другом, позвольте ему помочь Вам!
Что касается точки Ответвления/Соединительной линии - все должны всегда работать над соединительная линия , ответвление , es для скачков и POCs, тег все выпуски
Когда дело доходит до процессов, обычно выгодно найти методы , которые являются, относятся к Вам и затем создают микропроцессы вокруг них. Кроме того, используйте только те методы/процессы, которые Вы чувствуете, улучшают производительность. Наконец, будьте храбры - пробуют практику в течение недели или два, чтобы видеть, работает ли она с Вами; если это не делает, выбросьте его. Вы просто изучили еще один путь не для создания лампочки!
Это означает, делают намного меньшие фиксации. Чем чаще Вы фиксируете рабочие изменения, тем менее часто Ваша собственная рабочая копия когда-либо повреждается. Итерационная разработка запускается с Вас.
Интегрируйтесь рано, интегрируйтесь часто, интегрируйтесь быстро. Вместо 'ежедневной сборки', создайте каждый раз, когда кто-то фиксирует и фиксация часто (по крайней мере один раз в день, предпочтительно больше чем 2).
Важный: Быстрая обратная связь необходима для низкого дефекта. Если Ваша сборка займет много минут или даже более чем час, то в конечном счете Вы возненавидите сборку, учиться избегать его, выполнять ее как можно меньше, и т.д. Это - отбрасывания значения быстро на грани того, чтобы быть бесполезным, и Ваше дефектное количество начнет взлетать.
Инвестируют некоторое время впереди к получению Вашей сборки, работающей быстро. Если существует медленный материал, узнайте, почему это медленно, и устраните это. Если Вы не можете, то, по крайней мере, настроенный каскадные сборки так остальная часть сборки идут быстро (думайте < 2-5 минут), и продолжительный материал может следовать сразу после и взять, пока он хочет (хотя попытка сохранить это вершинами на менее чем 10 м).
не Может сказать это достаточно: Быстрый цикл обратной связи на изменениях чрезвычайно важен!
Прием к регистрации максимально часто, просто сделал некоторую тестовую передачу, хорошая проверка это в! Исправленный единственная ошибка, регистрируйте его! Попытайтесь найти, что smalles увеличивают возможный и регистрируют его! Это обладает дополнительным преимуществом фактического позволения и convinent, чтобы записать, что регистрация комментирует, что на самом деле релевантны, таким образом, это - хорошая премия.
Ofcourse, который требует, чтобы у Вас была среда CI, которая создает чаще, чем ночное, максимально часто действительно, является наилучшим вариантом там.
, О, и помнят, если это никогда повреждения, затем Вы делаете его неправильно. (Т.е. Вы чрезмерно консервативны, определенная поломка время от времени только идет, чтобы показать обнадеживающее продвижение ее.)
Простой: Никогда не регистрируйтесь в коде с [1 116] (известный) ошибки в нем. Это не означает, что Вы регистрируетесь однажды в день. Регистрация, когда Вам реализовали значимое изменение так другие разработчики, может получить доступ к нему.
Мы всегда интегрируемся локально, запускаем наши тесты против кода, и когда все передачи, мы регистрируемся. Я регистрируюсь приблизительно 20-30 раз в день при работе. Сервер сборки берет изменения, и он выполняет сборки против системы. Интеграция Continous (CI) является хорошей вещью. :D
Непрерывная Интеграция - Автоматизирует Ваши Сборки
, Начинаются с созданием успешно и сохраняют это тем путем как можно больше. Это важно в среде команды. Просто помните, что сборки повредятся. Ожидается, что они повреждают каждый однажды в некоторое время. Это - знак, что Вы просто непреднамеренно зарегистрировались в чем-то плохо, и Вы останавливаете то, что Вы делаете для создания сборки зеленой снова. Сервер сборки, который никогда не повреждал сборки, является предупредительным знаком!
я также соглашаюсь с ответом chadmyer: Независимо от того, что Вы решаете, это должно быть автоматически и автоматизировано. Лучшая вещь об автоматизации оснащает, чтобы сделать, этот вид материала для Вас - то, что Вы больше не должны думать об этом или не забывать делать это. Или как Чад сказал, Вы не прекращаете делать его. Я мог рекомендовать, предоставляют рекомендацию для инструментов CI, но взглянули здесь: , Какие инструменты Вы используете для Автоматизированных Сборок / Автоматизированные развертывания? Почему?
, После того как у Вас есть CI, можно получить более высокое качество, если можно ввести некоторый юмор (и позор) путем представления поврежденного маркера сборки! http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx
Использование Хороший Инструмент для Автоматизированных Сборок
Большинство людей в землепользовании.NET NAnt или сценарии MSBuild для автоматизации сборок, которые они могут позже сцепить до их сервера CI. Если бы Вы только начинаете, мое предложение состояло бы в том, чтобы использовать UppercuT, это - безумно простая в использовании платформа сборки, которая использует NAnt. Вот вторая ссылка с более глубокими объяснениями: UppercuT.
Ответвления по сравнению с Соединительной линией для Активной разработки
Вы не должны были бы переходить, если Вы не уезжаете, соединительная линия открываются только для выпусков (что означает, что все остальные работают в том же ответвлении Вами). Но у меня был бы CI и на соединительной линии и на ответвлении активной разработки.
Процесс Разработки программного обеспечения
Также для ответа на вопрос на процессе разработки программного обеспечения ответ является звучным да. Но не мчитесь ни во что, если радикальное изменение не требуется. Выберите процесс, который Вы хотите переместить к и медленно начинать принимать процессы. И оцените, оцените, оцените. Если конкретный процесс не работает на Вашу группу, фигура при выполнении чего-то не так или если просто необходимо устранить его. И затем сделайте. Безотносительно процесса Вы заканчиваете с потребностями работать на Вас, или он не будет работать.
Один, возможно, больше прагматического подхода должно иметь нулевые дефекты на соединительной линии и ответвление для всей разработки, затем наличие ежедневных сборок возможно и на соединительной линии и на ответвлениях, но нулевые дефекты не относятся к ответвлениям dev.
, В то время как может все еще быть определенный уровень клейма от наличия Вашего ответвления, повреждающего его сборки, это - меньше проблемы, чем повреждение соединительной линии.
Если Вы не пойдете домой, пока всех Ваших дефектов не не стало затем, Вы никогда не будете идти домой.
Мои мысли об этом - то, что ежедневная сборка должна быть автоматизирована в определенное время. Любой код, в котором не зарегистрировались, прежде чем это не становится созданным и при отсутствии checkins от кого-то в течение 2 дней (сборки) подряд затем система сборки, должен уведомить их и технический вывод, поскольку это - предупредительный знак.
Просмотр ответов, я удивлен, что никто не упомянул Разработку через тестирование. Если Вашей целью являются нулевые дефекты, это - лучшее место для запуска.
После этого я настоятельно рекомендовал бы программирование пары.
Наконец понимают, что инструменты как CruiseControl полезны, но, как Jim Shore сказал, , непрерывная интеграция является отношением не инструмент . Это - обязательство группы сохранить код, работающий, который является ключевым.
О нулевой дефектной стратегии: можно пойти домой, если известные ошибки находятся в коде. Больше о, дефекты должны быть починены, прежде чем новые опции реализованы.
, Который не должен запрашивать целую команду, но если разработчику присвоили ошибку, та ошибка имеет приоритет над новыми возможностями это, разработчики должны создать.
В зависимости от то, что Вы создаете, принимая подход, который не позволяются дефекты, не может быть соответствующим. Мое личное мнение - то, что это редко, если когда-нибудь.
смысл дефектной системы управления точно что - чтобы позволить Вам управлять дефектами. Если дефект является останавливающим шоу, затем уверенным, Вы, вероятно, не хотите регистрировать его, но если это - что-то незначительное или пограничный случай затем, может иметь смысл регистрировать его с известным дефектом, пока Вы отслеживаете его.
дефекты Разрешения для существования позволяют Вам сфокусироваться на более важных вещах - например, если у Вас только есть ограниченное количество времени в выпуске, у Вас не может быть времени, чтобы зафиксировать все, а также вложить всю функциональность, поэтому если это - выбор между фиксацией десяти пограничных случаев незначительные ошибки или создание части добавляющей значение функциональности затем, прагматический выбор может состоять в том, чтобы поставляться с известными ошибками.
я не говорю, что нулевые дефекты являются плохой идеей - на самом деле мы боремся за это к концу каждого цикла выпуска - но как много вещей в разработке программного обеспечения, прагматизм обычно работает лучше в реальном мире, чем пуританизм.