QA у DreamHost

by Guest Author
QA у DreamHost thumbnail

Я не хочу хвалитися, але у мене одна з найкрутіших робіт у світі. Я інженер з QA тут, у DreamHost, але що це означає? Час від часу я все ще отримую запитання про це, і легко забути, що весь світ не знає все про розробку програмного забезпечення та ролі, які відіграють різні групи, тому я вирішив трохи відступити та пояснити, як тут все працює.

Що саме, на вашу думку, ви тут робите?

Office-Space-homies4-1024x576

QA означає “Забезпечення якості”. Це може означати багато різних речей, але я люблю думати про це як про “ламання речей до того, як це зроблять наші клієнти”. Більш м’який погляд на це: тестування змін у нашому програмному забезпеченні перед їх впровадженням на виробничі машини, щоб спробувати виявити можливі проблеми. І може піти не так багато речей. Дозвольте я проведу вас через швидкий огляд!

Зміни-зміни-зміни

david-bowie-changes-resized-600

DreamHost має команду розробників, які працюють над продуктами, такими як DreamObjects та DreamCompute, а також над різними іншими проектами, про які ви, можливо, знаєте, такими як інтеграція з зовнішніми сервісами як CloudFlare.

Наші розробники використовують git для управління вихідним кодом проектів, над якими вони працюють. Більшість репозиторіїв для проектів з відкритим вихідним кодом, до яких ми долучаємось (або які створюємо), доступні на GitHub, але у нас також є внутрішній сервер, на якому працює Gerrit для перегляду коду. Коли зміни відправляються на GitHub або Gerrit, Jenkins запускає автоматизовані тести, написані розробниками та QA для нового коду. Jenkins інтегрується з Gerrit за допомогою кількох зручних плагінів, і автоматично відхиляє зміни, які порушують тести.

Щасливі до кінця своїх днів?

Єдина проблема цього підходу полягає в тому, що він працює лише тоді, коли є автоматизовані тести, які може запускати Jenkins. Іноді код, який змінюється, не має жодних автоматизованих тестів. Перед тим як ці зміни будуть впроваджені, їх потрібно переглянути комусь, крім розробників. Як інженер з якості, мені потрібно знати кілька речей, таких як:

Як це працювало раніше? Як це має працювати зараз? Чи є якісь особливі інструкції з налаштування? Де я можу знайти хороший буріто тут неподалік?

(Бурріто є важливою частиною процесу контролю якості.)

Озброївшись цими знаннями, я намагаюся використовувати нову функцію якомога більше. Наприклад, одна зі змін, яку ми внесли в панель з моменту мого приходу, це автоматичне (безкоштовне!) DNS хостинг, коли домен додається до акаунту. Тестування цього включало реєстрацію нових доменів, а також трансфер доменів від зовнішнього реєстратора, і перевірку автоматичного включення DNS хостингу для нового домену. Зазвичай, все не виходить ідеально з першої спроби, тому я подаю заявки на помилки розробникам, відповідальним за новий код, і працюю з ними, щоб переконатися, що ми маємо спільне розуміння того, що відбувається, що повинно відбуватися, і що я зробив, що це зламало.

А потім…

Це не зовсім повна історія, але інженерія випуску варта окремого посту. Сподіваюся, цей пост надав корисний високорівневий огляд QA в DreamHost, і в майбутніх записах я зможу детальніше розповісти про те, які інструменти ми використовуємо для автоматизованого тестування.