Этот пост изначально появился на jhall.io Анкет
В последнее время я много думал о том, как масштабируются DevOps. DevOps и связанные с ними практики получают большое внимание, когда речь заходит о масштабировании в таких крупных организациях, как Google и Netflix. Но Как насчет другой крайности очень маленьких команд?
Это список практик DevOps, которые я использую в крошечной шкале: сольные проекты.
В то время как большинство из этих практик предлагают немедленную выгоду, даже для команды одного человека, в большинстве случаев преимущество растет по мере роста команды. То есть ROI начинается позитивно и становится еще лучше с большим масштабом.
Непрерывная интеграция (CI) — это практика запуска автоматизированных тестов для каждого изменения кода, прежде чем слияние в производственную филиал. Это подразумевает, что у вашего кода есть тесты. Если у вас еще нет тестов, вы все равно можете настроить CI (запустив пустой набор тестов), затем начните добавлять тесты с этого момента. Это также идеальное место для запуска ваших любимых линтера.
Обычно это должно быть первое, что любая команда (или сольная разработчик) устанавливает, погода на новом проекте или при переходе на практики DevOps.
Независимо от того, используете ли вы управление размещенными версиями, например, GitHub или Gitlab, или размещение собственного управления версиями, настройка сервера непрерывной интеграции довольно проста. Если вы только начинаете, я рекомендую Gitlab с Gitlab ci/cd , просто потому, что инструменты предварительно связаны, просты в настройке, и либо дешево или бесплатно и с хорошей документацией.
Но если вам нравится делать что -то самостоятельно, вы можете сделать то же самое со своим собственным GIT или Subversion Server, а также локальной установкой Дженкинс или Зал Анкет
Несмотря на то, что это обычно не перечислено среди практик DevOps, я считаю, что это естественный и лучший способ управлять вашим рабочим процессом разработки. Для больших команд часто необходимо уменьшить Gitflow , или какая-то другая стратегия разветвления чрезмерного разжигания. Для сольного разработчика это может означать масштабирование. Но я думаю, что это того стоит!
Во многих сольных проектах обычно просто посвятить себя Мастер Всякий раз, когда изменение готово. Изменение в разработке на основе багажника является простым вопросом создания филиала перед созданием каждого изменения, а затем создание запроса на притяжение и объединение, как если бы оно было написано другим человеком.
Я делаю это для всех своих личных проектов, даже на этом веб -сайте! Преимущества могут быть не очевидны поначалу, но позвольте мне наметить несколько:
- Это обеспечивает четкое начало и остановку каждой части работы.
- Он сохраняет чистую историю GIT, сохраняя связанные коммиты вместе. Это особенно полезно, когда у меня может быть долгосрочная функция, которая в противном случае может быть разбита с помощью не связанных с этим исправлений ошибок или другими незначительными изменениями.
- Это позволяет легко просмотреть мой собственный код. Да, я просматриваю свой собственный код. Обычно я не рассматриваю свой собственный код так строго, как я делаю другой разработчик, но я всегда быстро проверяю свой пиар, чтобы убедиться, что я не случайно не совершал кода отладки, или не связанные с изменениями, или что я забыл включить новые файлы.
- В тесно связанных с номерами 2 и 3 выше, это позволяет переделать запросы на привлечение доработки перед слиянием. Я часто раздавил, переупорядочивался или даже полностью удаляю коммиты, перед слиянием.
- И, наконец, если я когда-либо принимаю запросы на привлечение других (как иногда случается в моих проектах с открытым исходным кодом), у меня уже есть чистый рабочий процесс.
Любое приложение, которое работает на сервере, должно быть настроено для непрерывного развертывания. Приложения, которые должны быть установлены (то есть мобильные приложения, или .deb пакеты) должны быть непрерывно упакованы (т.е. непрерывная доставка ), а не буквально развернутые.
Для устаревших проектов со сложными зависимостями это может быть очень трудно ввести в действие.
К счастью, для большинства сольных проектов это не должно быть непреодолимым препятствием. И если вы только начинаете, это еще проще. Для всех моих новых проектов я начинаю с Танцующий скелет Анкет Для этого сайта мой танцевальный скелет был простой, пустой веб -страницей, которая только что отображала мое имя. Но он автоматически развернулся в любое время, когда я слился с Мастер через Gitlab!
Как только у меня появился танцевальный скелет, я добавил тему и содержание.
Этот подход прекрасно работает с Kubernetes и Хелм , что, как оказалось, мое предпочтение, но его можно так же хорошо использовать с Хероку , при развертывании в стандартной виртуальной машине или в любой другой механизм доставки.
Регистрация — это еще одна часть головоломки DevOps, которая легко и полезно используется сольным разработчиком. Для одного из моих собственных приложений я использую оба loggly и Часовой Свободные планы хостинга. Есть также бесчисленное множество других вариантов, и вы всегда можете размещать свои собственные с помощью инструментов с открытым исходным кодом.
Если вы только начинаете новый проект, это идеальное время для добавления журнала, потому что модернизация журнала в существующее приложение всегда сложнее.
Ключ к регистрации, особенно для разработчика Solo, заключается в том, что он должен помочь быстро найти ошибки в производственном программном обеспечении. Это означает, что все условия ошибки не погребают, должны генерировать журналы (хорошая практика программирования), и что каждый журнал должен содержать соответствующую информацию для определения причины. Обычно это включает в себя информацию, такую как трассировку стека, имя службы, которая не удалась, и контекст сбоя, такую как аутентифицированный пользователь, или задание Cron, которая начала процесс.
Это не предназначено для того, чтобы быть исчерпывающим списком практик DevOps, который может или должен использовать сольный разработчик. Это только отправная точка. Одним из ключевых арендаторов DevOps является концепция постоянного улучшения.
Вы должны постоянно быть в поисках областей, где вы можете улучшить свои процессы и привычки.
Всякий раз, когда вы решаете проблему во второй или третий раз, подумайте, можно ли ее автоматизировать или иным образом сделать проще или быстрее.
Это третий раз, когда вы провели полчаса, отслеживая ошибку? Подумайте о том, смогут ли лучшие журналы или лучшие тесты ускорить процесс в следующий раз.
Вы боролись с ошибками вне памяти раньше? Подумайте, пришло ли время добавить мониторинг и оповещения сервера.
В дикой природе существует бесчисленное множество практик «DevOps», и, без сомнения, многие из них могут использоваться соло -разработчиками. Какие еще практики вы используете в своих сольных проектах? Я хотел бы прочитать ваши комментарии.
Оригинал: «https://dev.to/tinydevops/solo-devops-5eof»