Немного о личном
ГК «Невада» занимается дистрибьюцией, оптово-розничной торговлей. У нас сеть гипермаркетов и сеть минимаркетов по всему Дальнему Востоку.
Так уж получилось, что я человек с двойной должностью. С одной стороны я архитектор, с другой стороны – руководитель группы разработки.
С чего все начиналось
Еще в 2015 году по просьбе сообщества в версии платформы 8.3.6 появилась очень полезная штука – выгрузка конфигурации в файл, а вместе с этим и выгрузка внешних обработок, отчетов. Когда появились расширения, их тоже стало можно выгружать. Все это с целью возможности версионирования кода в системе контроля версий.
Но чуть раньше, еще в августе 2014 года, всеми нами уважаемый Алексей Лустин проводил вебинар на тему «Git-flow в 1С». Кто-нибудь видел этот вебинар? А кто уже перешел на Git, вообще пользуется им? А есть такие, кто еще думает переходить на Git? Или может быть только-только начал? Отлично, это я удачно зашёл.
Почему не взлетело
Почему чуда не произошло, и до сих пор лишь малая часть коллег пользуется Git. Кто-то думает, что слишком высокий порог вхождения. Я много слышал различных возражений от коллег-разработчиков и от менеджеров разных уровней. Самые популярные из них представлены на картинке.
В ходе своего доклада я постараюсь развеять эти сомнения.
Что такое система контроля версий
Для начала рассмотрим, что такое система контроля версий. Не все еще начали ею пользоваться. Это некое мероприятие или комплекс мероприятий, который позволяет нам ответить на следующие вопросы:
-
что и когда менялось;
-
кем менялось;
-
с какой целью.
Многие из вас, держу пари, пользовались системой контроля версий в той или иной мере.
-
Например, существует такое понятие, как локальная система контроля версий. Для меня это какие-то сетевые или локальные общедоступные файлы, папки. В их названии может фигурировать дата, время, какое-то краткое описание версий. Это ничто иное, как локальная система контроля версий.
-
Но когда речь заходит о том, чтобы с этими данными работало больше одного человека, на арену выходит понятие централизованной системы контроля версий. Классический пример ЦСКВ – наше любимое хранилище конфигураций. Данные, которые хранятся где-то централизованно на сервере, сервер управляет каким-то образом раздачей доступа, предоставляет возможность редактирования данных нескольким разработчикам.
Недостатки локальных и централизованных систем контроля версий
Главный недостаток как локальных, так и централизованных систем контроля версий – это их ненадежность. Если у нас что-то случится с данными, мы потеряем данные на сервере, мы потеряем сразу все, если не позаботимся о дополнительном бэкапировании этих данных.
С хранилищами тоже происходит много казусов: ошибки SDBL, ошибки целостности баз данных... И пока хранилище не починится, работа группы стоит, разрабатывать невозможно, захватить объект невозможно. Создаётся масса неудобств.
Преимущества распределенной системы контроля версий Git
В чем прелесть распределенной системы контроля версий, коей как раз является Git?
На картинке я попытался представить, как это выглядит. Это полностью распределенная система, в том смысле, что все данные, включая всю историю работы с этими данными, находятся абсолютно у каждого участника проекта, который подключен к репозиторию. Данными можно обмениваться как с сервером, так и с другими участниками проекта.
Но в чем прелесть Git? Работать можно локально и не обязательно иметь постоянное подключение к сети Интернет. Даже если вы улетите в космос, вы можете продолжать коммитить на своём ноутбуке. А вернувшись на землю, подключиться к интернету, синхронизироваться с сервером и радоваться актуальной версии вашего проекта.
Поговорим о преимуществах. Когда я работал архитектором в группе ЗУП, мне доверили архитектурировать еще одну конфигурацию – внедренный готовый проект. У нас есть такая служба, как служба проектов, которая умеет быстро внедрять красивые и интересные проекты, а потом передают их на поддержку архитекторам в службу разработки. Мне один такой проект достался. Он, действительно, был красивый: красивый интерфейс, формочки, кнопочки красиво работают. Но фишкой этого проекта было то, что он разрабатывался без поддержки архитектора. И то, что находилось внутри, никто не контролировал. Как только появилась необходимость вносить новый функционал в эту конфигурацию, естественно она оказалась неустойчивой, сразу полезли технические долги, ошибки. Стоимость сопровождения такой конфигурации резко возросла. Пришлось дополнительно брать на себя обязательства по контролю и рефакторингу всей системы.
К чему это я? К тому, что Code Review или инспекция кода, контроль чистоты архитектуры – это обязательная операция, которая должна присутствовать в вашей работе. Особенно если вы работаете с группой разработчиков, особенно если вы работаете в крупной корпорации.
В хранилище конфигураций есть для этого определенные инструменты, и хранилище само продолжает развиваться. На слайде вы можете посмотреть схему поиска изменений в одном из модулей. Именно так это выглядит при работе с хранилищем конфигураций.
Как только становится задача чуть посложнее, например, исследовать происхождение какой-то ошибки или историю возникновения строки кода и ее изменения во времени, то такая задача становится трудоемкой, если вообще возможной. При работе с хранилищем конфигураций это занимает достаточно много времени. Достаточно вспомнить сравнение двух версий из хранилища в какой-нибудь ERP, когда мы просим поднять интересующую версию из хранилища и сверить ее с текущей. Пошли, несколько часов попили кофе, приходим и обнаруживаем, что взяли не ту версию из истории. Такие случаи у нас тоже были. Потеря времени – это очень неприятно, хочется, чтобы всё работало быстро.
И тут нам на помощь приходит Git. Это консольная программа, но для того, чтобы приобщить к ней огромную армию пользователей Windows и нас, специалистов 1С (мы ведь тоже не любим консольные программы, не любим командную строку, мы любим на кнопочки нажимать), было разработано огромное количество всяких графических оболочек, которые представляют информацию в таком красивом виде.
На слайде выше – фрагмент главного окна моего любимого SourceTree. Сразу видно, кто, когда и куда помещал изменения, в рамках какой задачи, зачем, комментарий, что там поменялось, вплоть до строки кода.
Git позволяет такую информацию получать достаточно быстро, я бы сказал мгновенно.
Говоря о преимуществах Git, мы возвращаемся немного в историю его происхождения. Когда Линус Торвальдс в 2005 году дал задачу разработать систему контроля версий, ключевыми требованиями были:
-
производительность;
-
возможность работы большого количества разработчиков (больше тысячи разработчиков);
-
высокая скорость работы.
Все эти цели были достигнуты.
Скорость работы. Git, действительно, позволяет получать любые отчеты практически мгновенно при анализе истории из данных, чем не может похвастаться хранилище.
Ветвление разработки. В хранилище мы знаем, что коммиты у нас происходят строго линейно, и когда мы собираем релиз, то выколупать доработки определенных задач или подзадач становится проблематично. У нас был такой инцидент, когда в нашей основной товаро-учетной системе накопилось очень много ошибок. На их устранение подключили целую армию программистов. Было очень много фиксаций в хранилище конфигураций, и мы зашли в тупик с вопросом: «А что же делать со всеми этими задачами? Кто их будет тестировать? Армии тестировщиков нет!».
Решили, что надо их как-то ранжировать по приоритетам, протестировать немного в другой последовательности, нежели они были закоммичены в разработку, и пустить в релиз. Как это сделать с хранилищем? Никак!
Были, конечно, приняты определенные управленческие решения: что разработчики сами должны следить за порядком, брать на себя функции тестирования и так далее. Но это уже вопрос десятый.
Другое дело, когда мы говорим о работе с Git.
Я не зря на предыдущем слайде показал именно этот фрагмент нашего репозитория. Это огромная пачка фич, которая стекается в ветку develop – не что иное, как одна пачка задач, которые сделали несколько разработчиков и одновременно послали pull request в основной ствол разработки. В любой момент эти задачи можно было принять и отправить в продакшен. Очень удобно. Да, Git позволяет управлять именно такой очень гибкой и удобной системой ветвления.
Детальная история. Я про нее уже упомянул.
Версионирование внешних файлов. Возможность версионировать, помимо конфигурации, любые внешние файлы, которые прямо или косвенно связаны с нашим проектом – это, пожалуй, моя самая любимая фича Git. Это не только внешние обработки, печатные формы, которые, как я уже сказал, тоже раскладываются в исходники. Это любые файлы, которые, так или иначе, можно представить текстом. XML-файлы (те же правила обмена), какие-то настроечные JSON-файлы, скрипты, написанные на чем угодно. Добавляете в свой проект в отдельные папочки, настраивайте структуру хранения этих папок, а за историей версий следит сам Git. Вам только остаётся почаще делать коммиты.
Немного холивара
Представлю плюсы и минусы Git и хранилища, о которых чаще всего мы сами говорим или слышим от наших коллег.
Порог вхождения. Так уж получилось, что у наших коллег сложился обманчивый стереотип, что Git – это что-то сложное, неизведанное, какая-то непонятная система, на которую нужно потратить время, чтобы ее изучить и понять. Этот стереотип мы обсудим чуть позже. В конце доклада я сделаю вам небольшой подарок.
Возможность параллельной работы с объектом, то, как работать с объектом – это самое популярное возражение сторонников хранилища. Здесь мы приходим к тому, что при переходе на Git, мы принимаем на себя иную культуру работы с кодом. Если раньше мы не задумывались о том, какие изменения мы вносим, как они повлияют и будут коррелироваться с изменениями других разработчиков, то теперь, работая с Git, параллельно дорабатывать один и тот же модуль может хоть сотня разработчиков. Но при слиянии кода перед нами встает задача дополнительно проанализировать конфликты и принять решение о том, какие изменения в каждой строке кода мы принимаем для того, чтобы в продуктиве получить то, что мы хотим получить. Здесь на передний план выходит та самая пресловутая операция Code Review (инспекции кода), которая для нас становится неизбежной частью процесса разработки. Те, кто начинает работать с Git, думает, что это плохо, что это неудобно, что это дополнительные трудозатраты. Но это хорошо, потому что это повышает качество вашей разработки и, в конце концов, откликается снижением себестоимости строки кода. Это та самая «чистая архитектура», о которой писал Роберт Мартин.
Open Source – вишенка на торте. Если у вас есть какой-то интересный проект, стартап, которым вы хотите поделиться с сообществом и желаете, чтобы в ваш проект коллеги со всего мира (да что там мира, России!) вносили изменения и добавляли полезную функциональность, то welcome на GitHub. Выкладывайте свои разработки и добро пожаловать в мир Open Source.
Как начать работать с Git
Ну что, появилось желание пощупать Git?
Подумаем о том, где и какие инструменты мы будем использовать, и как вообще можно выстроить работу нашей группы при использовании Git.
В своем прошлом докладе я подробно рассказывал про работу в группе с хранилищем конфигураций. Неважно, какую схему вы выберите (одно, два или три хранилища), но если у вас версия платформы ниже 8.3.6 или вы работаете с обычными формами, то вам ничего не остаётся, кроме как продолжить использовать хранилище.
Есть интересный подход, который выложен на ИТС, – это разветвлённая система разработки с использованием хранилищ, которая очень напоминает Git-Flow, реализованное на хранилищах. Поэтому если у вас нет возможности использовать Git, но хочется попробовать схему Git-Flow, можете попробовать эту схему.
Если же вас не ограничивают возможности платформы, то самое время попробовать Git.
Как его начал использовать я? И один из вопросов, который мне задали в кулуарах, – начиная с какого количества разработчиков стоит начать использовать Git? Отвечаю: от одного. Я начал пользоваться Git сам для себя. Начал с того, что запушил в репозиторий шаблоны текстов кода, которыми я активно пользуюсь. Мне показалось это очень удобным, и я решил подключить к этому свою группу разработки. Мы добавили туда внешние отчеты, обработки и расширения конфигурации, потом правила обмена.
На сегодняшний день внедряем автотесты – feature файлы хранятся в том же репозитории, что тоже очень удобно, потому что сразу видно, какая фича в рамках какой задачи и с какими модулями одновременно была доработана.
Дальше - больше: всё, что прямо или косвенно касается этого проекта, добавляется в Git. Ничего не теряется. Более того, после того как мы начали использовать Git, освободилось много времени на действительно полезную работу. Голова и руки освобождаются от необходимости следить за версиями, мучиться вопросами, что куда положить, как хранить. Все это на себя успешно берет Git.
Конфигурацию тоже можно разложить в Git. Здесь у нас набор инструментов oscript-library, который до сих пор очень успешно используется даже на крупных проектах.
И конечно же – это для кого-то любимый, для кого-то ненавистный инструмент EDT, вокруг которого сейчас ходит много споров. Лично я смотрю на его развитие очень оптимистично, и верю, что в скором будущем мы получим тот долгожданный релиз, когда можно будет в EDT эффективно работать даже с очень крупными проектами.
Что нужно, чтобы начать?
Нужно понизить порог вхождения в Git. Чтобы он не казался таким страшным и непонятным для наших коллег, я решил опубликовать на Инфостарте серию статей о том, как подключиться к команде, какой софт поставить, как его поставить. Там всё это очень подробно расписано. Если вы задумываетесь о том, чтобы начать использовать Git, пользуйтесь этой информацией.
Спасибо!
**********************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.
*************
