Мой первый вклад с открытым исходным кодом
Почему вам тоже стоит попробовать
Борьба с синдромом самозванца
Я знаю, что участие в проекте с открытым исходным кодом - это ежедневная задача для многих разработчиков, но я уверен, что многие еще не решаются на этот шаг. Они не думают, что участие в проекте с открытым исходным кодом предназначено для них. В большинстве случаев такая ситуация возникает из-за того, что они не чувствуют себя достаточно уверенно, чтобы участвовать. Немного о синдроме самозванца. Это был мой случай ...
…до сих пор. Мне посчастливилось быть частью организации (Ingenico Group), которая поощряет участие в открытии исходного кода, и на этот раз я воспользовался своим шансом в одном проекте.
В этой статье я расскажу вам о внутреннем процессе, с которым я столкнулся, когда решил участвовать в проекте с открытым исходным кодом. Вы узнаете, какие шаги я предпринял, как ожидаемые, так и неожиданные.
Найдите проект, который вам подходит
В моем случае мне удобнее работать с проектами Javascript и NodeJs.
В моей компании мы реализовали несколько проектов React и, конечно же, конвейер транспиляции NodeJs, который идет вместе с ним. Чтобы наши проекты были в безопасности, мы решили проверить их зависимости на наличие уязвимостей. Этот процесс был запущен в рамках нашей непрерывной интеграции.
По логике вещей, мы сначала использовали «npm audit», поскольку это встроенное решение. Но мы начали задаваться вопросом, можем ли мы найти лучший инструмент. Да, «npm audit» имеет некоторые ограничения.
Во-первых, об одной и той же уязвимости сообщается несколько раз. Действительно, если несколько пакетов зависят от одного и того же зараженного пакета, уязвимость будет сообщаться для каждого пакета, который ее импортирует. Это затрудняет поиск первопричины обнаруженной проблемы.
Кроме того, встроенный инструмент аудита npm недостаточно гибкий для наших нужд, мы хотели бы иметь возможность помечать уязвимость как известную и при этом продолжать работу над нашими сборками. Это может произойти, когда после анализа мы решим, что конкретная уязвимость не влияет на нас, или когда мы решим дождаться, пока автор зависимости исправит свой код.
После некоторого исследования мы решили попробовать auditjs. Этот проект поддерживается Sonatype, компанией, создавшей репозиторий Nexus, и использует вручную подобранный индекс уязвимостей: OSS.
Это решение также позволяет занести в белый список известные уязвимости. Это позволяет нам контролировать, должна ли конкретная проблема блокировать нашу сборку или нет.
Вывод инструмента также стал более читаемым и понятным.
Начните с малого
После попытки и успешной интеграции этого инструмента в один из наших проектов мы столкнулись с проблемой при использовании этого решения на нашем сервере CI: инструмент не принимает конфигурацию прокси-сервера http.
В нашей организации CI-серверы не имеют прямого доступа к Интернету и должны проходить через прокси-сервер, где соединения тщательно отслеживаются, а трафик разрешается на основе списка безопасных веб-сайтов.
Я посмотрел на код и обнаружил, что инструмент использует node-fetch для выполнения сетевых подключений. Таким образом, решение заключалось в использовании пакета npm под названием «https-proxy-agent». Эта библиотека позволяет создать http-агент для перехода к node-fetch во время соединения.
Пришло время интегрировать это решение в их код.
Как внести свой вклад
Я ежедневно работаю с git на работе, клонируя репозитории, создавая ветки, фиксируя код, объединяя, перебазируя и т. Д., Но я никогда не делал этого для проекта с открытым исходным кодом.
В Github процесс немного другой. Хотя вы можете клонировать чужой репозиторий на своем компьютере, вы не можете отправить туда ветку, так как у вас нет прав. Сначала вам нужно разветвить проект.
Поскольку я делаю это в рамках своей работы в Ingenico, я разделила это на организацию GitHub, созданную моей компанией.
Как только вы станете частью организации GitHub (вас должен пригласить владелец организации), вас спросят, где вы хотите разветвить проект (в ваших собственных репозиториях или репозиториях вашей организации).
Я раздвоил его в репозиториях своей организации и клонировал локально. На этом этапе вы можете внести свои изменения, создать ветку, зафиксировать свой код, как обычно.
После этого вы можете отправить свою ветку в репозиторий. Github обнаружит, что вы отправили ветку в проект, который вы разветвил, и предложит вам создать запрос на вытягивание для исходного проекта (либо по ссылке, предоставленной при отправке ветки, либо со страницы репозитория в вашей учетной записи GitHub).
Затем вы находитесь на странице для создания запроса на перенос для слияния вашего кода с исходным репозиторием. Здесь вы найдете особый набор правил репозитория.
В случае с auditjs они напомнили добавить в документацию примечание для описания новой функции, которую я сначала забыл сделать.
После того, как вы соответствуете требованиям репозитория, вы можете дать комментарий, объясняющий цель вашего коммита, и отправить его.
Взаимодействие с сопровождающими проекта
После того, как вы создали свой пул-реквест, вам нужно дождаться обратной связи от разработчиков репозитория. В моем случае мне повезло: на следующий день я получил ответ.
Оттуда с ними происходит обсуждение, делаются небольшие комментарии. Я вношу запрошенные изменения, и примерно через 2 дня (мы находимся в разных часовых поясах) запрос на вытягивание принимается и объединяется ими.
Надо сказать, что взаимодействие с сопровождающими было очень добрым и дружелюбным. В конце концов, они просто другие разработчики, которые ценят помощь так же, как и мы.
На следующий день был выпущен новый выпуск с моими изменениями, и теперь я могу использовать этот инструмент в нашем конвейере CI.
Мои выводы из этого
Внести свой вклад в проект с открытым исходным кодом действительно несложно. На самом деле это просто еще одна задача разработки проекта, начатого кем-то другим. Насколько это может отличаться от работы над проектом, созданным коллегой. Да, вы должны прочитать и понять код. Да, вам необходимо адаптироваться к архитектуре / структуре кода конкретного проекта. Но вам все равно следовало делать это в собственной компании. И если ваш вклад может быть ценным для проекта и, скорее всего, так и будет, сразу же внесите свой вклад.
Сообщество в целом дружелюбное и доброжелательное. В конце концов, сопровождающие - это такие же разработчики, как и вы. Они потратили свое время на то, во что верили. Они будут более чем счастливы получить некоторую помощь.
Если вы никогда не пробовали внести свой вклад, попробуйте, и вы будете гордиться собой и встретитесь с другими разработчиками. И, кто знает, вы можете когда-нибудь встретиться с некоторыми из них на конференции.
Спасибо Эльде Сулоллари за ее обзор и конструктивные комментарии.
