В разрезе: новостной агрегатор на Android с бэкендом. Система контроля версий

    Вводная часть (со ссылками на все статьи)

    Когда я выделил необходимое время для написания статьи об опыте использования системы контроля версий, я переговорил с несколькими людьми занимающимися разработкой (новичками и профессионалами) о системах контроля версий – плюсы и минусы использования, особенности их систем, сценарии использования. Разговор всегда начинался примерно одинаково: каждый считал, что может ответить на все мои вопросы и поделиться своим опытом, однако заканчивался разговор по-разному: кто-то прямо говорил, что в тонкостях не специалист, кто-то говорил, что это мне не понадобится – отсюда можно сделать вывод, что системы контроля версий не настолько простой инструмент совместной работы как многие о нём думают.

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

    • Подключение дополнительных членов команды к проекту и начало работ с единым репозиторем – при использовании системы контроля версий уже отработаны вопросы: какое хранилище, какие средства для работы с ним, как структурирован проект по репозиториям, как осуществляется именование веток и тэг. При отсутствии – придётся всё эти вопросы прорабатывать с начала и тратить на это время;
    • Просмотр изменений (иногда просто для понятия как сильно изменился класс за последнее время);
    • Оценка своей собственной продуктивности в количестве строк кода (субъективный показатель, но для меня иногда и он важен);
    • Защита от случайного удаления файлов или внесение нежелательных результатов и возможность возврата всего к предыдущему состоянию;
    • Проверка работы алгоритма с созданием отдельной ветки (в рамках которой меняются не только пара классов, а и конфигурационные файлы) и необходимость возврата к предыдущему варианту (в случае если надежды не оправдались);
    • Необходимость временного представления доступа на чтение к актуальной версии исходных текстов;
    • Дополнительные сценарии, которые редки для разработчика-одиночки и обязательны для группы или фирмы:

      • Системы интеграционного тестирования, которые запускают тесты после обнаружения коммита в основной или специализированной ветке;
      • Системы постоянной доставки обновлений, который так же запускают свою работу после обнаружения необходимых изменений в ветка для развёртывания;
      • Иерархические системы внедрения кода в основные ветки, при которых подготовленные изменения проверяются более опытными или специально предназначенным специалистами по своим критериям (безопасность, простота, следование стандартам и прочее-прочее…) – хороший пример описания подобных подходов представлен тут (Распределённые рабочие процессы).

    Небольшое отступление от очевидных вещей:


    После некоторого времени работы в качестве программиста приходит понимание, что результат работы современного разработчика (особенно в модном ныне направлении DevOps) это не только исходники программы, но так же данные для тестирования, настройки стендов тестирования, скрипты развёртывания стендов, документация и прочее, что позволяет не только получить исполняемый код, но и сконфигурировать необходимую среду для его исполнения, а так же сформировать документацию для разработки и эксплуатации проекта другими участниками. Так, что если в процессе работы используются какие-то общие для всех настройки, скрипты и данные, которые должны разделяться всему участниками проекта – подходящее место для их хранения и способ контроля их своевременной актуализации – система контроля версий.

    Все задачи, которые передо мной стояли, и которые я мог себе вообразить в ближайшее время решались mainstream’овскийм решением – git и соответствующим хостингом для него — GitHub.

    Интересные ссылки про git: книга | видео от Yandex.

    Выбор GitHub для меня был обусловлен следующими критериями:

    • Приемлемыми ценами для хостинга приватных репозиторев;
    • Возможность просмотра статистики работы (ссылка);
    • Возможностью ведения wiki по проекту/модулю проекта;
    • Приличным интерфейсом для работы с репозиториями и коммитами;
    • Наличием уже некоторого кол-ва репозиториев, созданных при прохождении курсов на Coursera.

    В качестве клиента мною используется обычный SmartGit и клиент командной строки (знание его в некоторые моменты просто обязательно).

    Для тех, кому всё это кажется элементарными и очевидными вопросами я оставил пару вещей, аналога которых я не нашёл для других систем контроля версий и других git-хостингов:

    • Git submodules – Подмодули позволяют содержать один Git-репозиторий как подкаталог другого Git-репозитория. Это даёт возможность клонировать ещё один репозиторий внутрь проекта, храня коммиты для этого репозитория отдельно.
    • GitHub’s Deploy Keys – позволяют получать доступ к репозиторию на чтение / запись с помощью ssh-ключей, при этом каждому можно выдавать свой ключ и как результат — доступ отозвать по собственному желанию (просто-напросто убрав соответствующий закрытый ключ). В моём случае данный функционал используется для системы последовательной интеграции для получения необходимого доступа к репозиторию соответствующего модуля. Описание функционала также доступно тут.

    Спасибо за внимание!
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 2
    • +1

      Мда, не статья, а прям статьище! Хотя она поместилась бы в 2 предложения: Всегда используйте гит (или другую vcs). Я пользуюсь гит и гитхаб, потому что у меня там были проекты, а другие гит-хостинги не такие модные и мейнстримовые.


      Кстати, почему не рассматривался битбакет с его бесплатными приватными репозиториями (в командах менее 5-ти людей)?

      • 0
        Люблю неоскорбительный сарказм :) Можно конечно и так прочитать. Однако смысл был в том, что бы убедить разработчиков использовать VCS (а таких которые не используют его в разработке есть. их работа это боль и они этого не видят), причём с пояснениями ПОЧЕМУ. Всунуть в 2 предложения это было выше моих сил.

        В других гит-хостингах есть аналог «Deploy Keys»?

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.