Имея достаточно денег и удачи, вы можете создать такой поп-феномен, как One Direction. Но если вы хотите создать популярный проект с открытым исходным кодом, никакие деньги не принесут успеха.

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

Хотя не было никакой гарантии, что Artillery станет большим успехом, Велдстра и сообщество Artillery сделали несколько первых ставок на технологии – например, на JavaScript и YAML, – которые оказались дальновидными. Это предполагает, что они будут продолжать делать разумные инвестиции, которые помогут улучшить межфункциональное сотрудничество внутри предприятия.

Однако ключ к ранним ставкам Велдстры – это то, чему может подражать любой: залезть в окопы, взять на себя ответственность. Вот как этот подход окупился для артиллерийского сообщества.

Чесать зуд

Сегодня Artillery получает несколько сотен тысяч загрузок каждый месяц, что на 15 процентов больше по сравнению с предыдущим месяцем. То, что Велдстра начинала как индивидуальный проект в 2016 году, теперь привлекает десятки участников и пользователей практически из любой отрасли, о которой вы только можете подумать, даже от службы лесного хозяйства, отмечает Велдстра.

Все это стало результатом выступления Велдстры на конференции пять лет назад. Он говорил о приложении для чата, которое создавал, но также упомянул инструмент нагрузочного тестирования, который он создал, чтобы помочь с этим. Практически все вопросы аудитории были сосредоточены на тестере нагрузки, который он вскоре отправил на GitHub по прихоти, чтобы посмотреть, будет ли там интерес. Там было. «Я разместил это на GitHub, и, прежде чем я это узнал, я получал PR-запросы, комментарии и запросы на новые функции», – вспоминает Велдстра. “Это было здорово.”

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

Если вы обратите внимание на рынок тестирования производительности, вы знакомы с Apache JMeter. Вельдстра тоже. Но во время работы над приложением чата в YLD ему потребовался другой подход, чем JMeter или другие предлагаемые варианты.

Одной из проблем JMeter был его графический пользовательский интерфейс, который мог быть идеальным для многих пользователей, но не для Veldstra. «Как разработчик, я хотел что-то, что хорошо работало бы с системой управления версиями; то, что позволило бы мне просто писать код », – говорит он. «Я не хотел щелкать мышкой, чтобы собрать свой сценарий».

Использование JMeter «действительно подробного XML-формата» сделало его еще более недружелюбным для использования в операциях управления версиями, добавляет Велдстра. Были и другие проблемы:

JMeter было очень сложно контейнеризовать, потому что он написан на Java. Сегодня все немного проще, но тогда это был кошмар. И это было важно, потому что было действительно сложно запускать тесты, написанные с помощью JMeter, как часть вашего конвейера непрерывной интеграции. Вероятно, это было требование номер один [for users] которые хотят регулярно запускать эти тесты производительности в рамках процесса выпуска.

И было очень сложно расширить JMeter для тестирования чего-либо, кроме HTTP. Это было очень важным требованием для нас, потому что мы писали эту систему реального времени, которая говорила о чем-то другом, кроме HTTP, и в то время я действительно пытался расширить JMeter, чтобы добавить поддержку этого протокола, и это было слишком сложно.

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

Но Велдстра не просто думал о своих потребностях в качестве разработчика. Он был сосредоточен на межфункциональном сотрудничестве с операционной командой. Фактически, в 2016 году тестирование производительности считалось «работой QA», о чем разработчики особо не задумывались. Это изменилось. Сегодня существует «движение сдвига влево» для создания экземпляров тестирования на ранних этапах процесса разработки.

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

Заглядывать за углы

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

«Если вы посмотрите на скрипты Artillery, вам действительно не нужно много знать о базовых стеках, которые они тестируют», – говорит Велдстра. «На самом деле, они очень близки к английскому». YAML стал неотъемлемой частью коллектива Kubernetes, но еще в 2016 году это не обязательно было очевидной ставкой.

Как и в случае с YAML, Велдстра уловил динамику развития Docker и облака на ранней стадии, когда они еще только зарождались. «Вы могли видеть, что дела идут именно так, – вспоминает он. «Так что имело смысл создать что-то, что будет подключаться к этим новым рабочим процессам и поддерживать направление, в котором движется мир».

Точно так же большая ставка Велдстры на JavaScript и Node.js сегодня кажется очевидной, но в 2016 году Node.js было всего несколько лет. «Совершенно очевидно, что для Node.js будет создано множество библиотек», – сказал он. помнит. Если бы это подтвердилось, это упростило бы расширение скриптов нагрузочного тестирования Artillery.

Пример Artillery показывает, что инновации с открытым исходным кодом (или, на самом деле, Любые инновации), скорее всего, произойдет, когда разработчик или специалист по эксплуатации глубоко увяз в проблеме. Это дает им лучшую точку обзора, чтобы увидеть неровности, которые необходимо сгладить. «Это действительно помогает, – советует Велдстра. «Я не знаю, как это сделать, не имея практического опыта. Как практик, как человек, который работает с инструментами каждый день и сосредоточен на разработчиках, вы понимаете, к чему все идет ».

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

Подробнее об открытом исходном коде:

Авторские права © 2021 IDG Communications, Inc.


#Артиллерия #успехи #открытым #исходным #кодом #между #разработчиками #операторами

Source link