Като SET, работещ по множество проекти, виждам всеки ден разликата между хакерски проект с 1-секундна тестова верига за обратна връзка и проекти с лоша изолация, които се нуждаят от толкова много външни ресурси, за да стартират, че не могат да бъдат надеждно тествани локално, а само на специален набор от виртуални машини.

хакерски

Предполагам, че индустрията се е насочила към аутсорсинг на ключови услуги като бази данни или разпределени файлови системи по този начин, но без необходимата тестова инфраструктура, която да поддържа проектите хакажни. Докато Google разполага с мащаба да превърне опашката за фиксиране в реалност, тази ситуация хапе твърди ентусиасти в облака, които не отделят време за осигуряване на среди за тестване и зависимости.

Нали. Не е задължително лоша ситуация, когато не можете да проведете тест на работната си станция, стига да е лесно и бързо да стартирате в магическата среда някъде другаде. Например, ако пуснете нещо в терминал и получите резултатите веднага, не е голяма работа, ако в действителност се извика друга машина зад кулисите.

Ако трябва да ssh някъде, да нулирате състоянието на машината и след това да стартирате на ръка, това е ужасна пречка за хакване. По същия начин е проблем, ако нямате достатъчно устройства за всички разработчици в пула с магически устройства. В този случай вашата компания хвърля пари, инженерния морал и конкурентоспособността през прозореца в опит да спести пари.

Не знам много за тестовите инструменти за облак, но споменах инструментите за отстраняване на грешки в Google Cloud в предишната статия: https://cloud.google.com/debugger/.

Също така споменавате, че не всеки има ресурси за изграждане на опашка за фиксиране. Това със сигурност е вярно и е прекалено много за много проекти. Повечето проекти добре изпълняват модулните тестове в presubmit (ако са достатъчно бързи поне) и се изпълняват на всички целеви платформи за доставка в postubmit. Имате нужда от нещо масивно като опашката за фиксиране, ако правите стотици промени в кода на ден.