→ Вводная часть (со ссылками на все статьи)
Когда я выделил необходимое время для написания статьи об опыте использования системы контроля версий, я переговорил с несколькими людьми занимающимися разработкой (новичками и профессионалами) о системах контроля версий – плюсы и минусы использования, особенности их систем, сценарии использования. Разговор всегда начинался примерно одинаково: каждый считал, что может ответить на все мои вопросы и поделиться своим опытом, однако заканчивался разговор по-разному: кто-то прямо говорил, что в тонкостях не специалист, кто-то говорил, что это мне не понадобится – отсюда можно сделать вывод, что системы контроля версий не настолько простой инструмент совместной работы как многие о нём думают.
Вопрос применения системы контроля версий для создаваемого кода и артефактов при работе в одиночку открыт. В связи с этим предлагаю сыграть в игру – я буду писать ситуации, при которых использование системы контроля версий мне помогло и убедило меня в необходимости её использования, а Вы будете писать — как можно решить эту задачу без неё (если желающих не найдётся – я пойму):
После некоторого времени работы в качестве программиста приходит понимание, что результат работы современного разработчика (особенно в модном ныне направлении DevOps) это не только исходники программы, но так же данные для тестирования, настройки стендов тестирования, скрипты развёртывания стендов, документация и прочее, что позволяет не только получить исполняемый код, но и сконфигурировать необходимую среду для его исполнения, а так же сформировать документацию для разработки и эксплуатации проекта другими участниками. Так, что если в процессе работы используются какие-то общие для всех настройки, скрипты и данные, которые должны разделяться всему участниками проекта – подходящее место для их хранения и способ контроля их своевременной актуализации – система контроля версий.
Все задачи, которые передо мной стояли, и которые я мог себе вообразить в ближайшее время решались mainstream’овскийм решением – git и соответствующим хостингом для него — GitHub.
Интересные ссылки про git: книга | видео от Yandex.
Выбор GitHub для меня был обусловлен следующими критериями:
В качестве клиента мною используется обычный SmartGit и клиент командной строки (знание его в некоторые моменты просто обязательно).
Для тех, кому всё это кажется элементарными и очевидными вопросами я оставил пару вещей, аналога которых я не нашёл для других систем контроля версий и других git-хостингов:
Спасибо за внимание!
Когда я выделил необходимое время для написания статьи об опыте использования системы контроля версий, я переговорил с несколькими людьми занимающимися разработкой (новичками и профессионалами) о системах контроля версий – плюсы и минусы использования, особенности их систем, сценарии использования. Разговор всегда начинался примерно одинаково: каждый считал, что может ответить на все мои вопросы и поделиться своим опытом, однако заканчивался разговор по-разному: кто-то прямо говорил, что в тонкостях не специалист, кто-то говорил, что это мне не понадобится – отсюда можно сделать вывод, что системы контроля версий не настолько простой инструмент совместной работы как многие о нём думают.
Вопрос применения системы контроля версий для создаваемого кода и артефактов при работе в одиночку открыт. В связи с этим предлагаю сыграть в игру – я буду писать ситуации, при которых использование системы контроля версий мне помогло и убедило меня в необходимости её использования, а Вы будете писать — как можно решить эту задачу без неё (если желающих не найдётся – я пойму):
- Подключение дополнительных членов команды к проекту и начало работ с единым репозиторем – при использовании системы контроля версий уже отработаны вопросы: какое хранилище, какие средства для работы с ним, как структурирован проект по репозиториям, как осуществляется именование веток и тэг. При отсутствии – придётся всё эти вопросы прорабатывать с начала и тратить на это время;
- Просмотр изменений (иногда просто для понятия как сильно изменился класс за последнее время);
- Оценка своей собственной продуктивности в количестве строк кода (субъективный показатель, но для меня иногда и он важен);
- Защита от случайного удаления файлов или внесение нежелательных результатов и возможность возврата всего к предыдущему состоянию;
- Проверка работы алгоритма с созданием отдельной ветки (в рамках которой меняются не только пара классов, а и конфигурационные файлы) и необходимость возврата к предыдущему варианту (в случае если надежды не оправдались);
- Необходимость временного представления доступа на чтение к актуальной версии исходных текстов;
- Дополнительные сценарии, которые редки для разработчика-одиночки и обязательны для группы или фирмы:
- Системы интеграционного тестирования, которые запускают тесты после обнаружения коммита в основной или специализированной ветке;
- Системы постоянной доставки обновлений, который так же запускают свою работу после обнаружения необходимых изменений в ветка для развёртывания;
- Иерархические системы внедрения кода в основные ветки, при которых подготовленные изменения проверяются более опытными или специально предназначенным специалистами по своим критериям (безопасность, простота, следование стандартам и прочее-прочее…) – хороший пример описания подобных подходов представлен тут (Распределённые рабочие процессы).
Небольшое отступление от очевидных вещей:
После некоторого времени работы в качестве программиста приходит понимание, что результат работы современного разработчика (особенно в модном ныне направлении DevOps) это не только исходники программы, но так же данные для тестирования, настройки стендов тестирования, скрипты развёртывания стендов, документация и прочее, что позволяет не только получить исполняемый код, но и сконфигурировать необходимую среду для его исполнения, а так же сформировать документацию для разработки и эксплуатации проекта другими участниками. Так, что если в процессе работы используются какие-то общие для всех настройки, скрипты и данные, которые должны разделяться всему участниками проекта – подходящее место для их хранения и способ контроля их своевременной актуализации – система контроля версий.
Все задачи, которые передо мной стояли, и которые я мог себе вообразить в ближайшее время решались mainstream’овскийм решением – git и соответствующим хостингом для него — GitHub.
Интересные ссылки про git: книга | видео от Yandex.
Выбор GitHub для меня был обусловлен следующими критериями:
- Приемлемыми ценами для хостинга приватных репозиторев;
- Возможность просмотра статистики работы (ссылка);
- Возможностью ведения wiki по проекту/модулю проекта;
- Приличным интерфейсом для работы с репозиториями и коммитами;
- Наличием уже некоторого кол-ва репозиториев, созданных при прохождении курсов на Coursera.
В качестве клиента мною используется обычный SmartGit и клиент командной строки (знание его в некоторые моменты просто обязательно).
Для тех, кому всё это кажется элементарными и очевидными вопросами я оставил пару вещей, аналога которых я не нашёл для других систем контроля версий и других git-хостингов:
- Git submodules – Подмодули позволяют содержать один Git-репозиторий как подкаталог другого Git-репозитория. Это даёт возможность клонировать ещё один репозиторий внутрь проекта, храня коммиты для этого репозитория отдельно.
- GitHub’s Deploy Keys – позволяют получать доступ к репозиторию на чтение / запись с помощью ssh-ключей, при этом каждому можно выдавать свой ключ и как результат — доступ отозвать по собственному желанию (просто-напросто убрав соответствующий закрытый ключ). В моём случае данный функционал используется для системы последовательной интеграции для получения необходимого доступа к репозиторию соответствующего модуля. Описание функционала также доступно тут.
Спасибо за внимание!
