1. Стоит ли внедрять репозитории для хранения кода? Какие преимущества у этого подхода?
Без всяких разговоров, стоит. Преимущества этого подхода должны быть очевидны для любой компании, которая считает свой уровень чуть серьезнее студенчества, это как разница между ведением бухучета в 1C и Excel.
Безусловно, стоит. Репозитории позволяют снизить риски потери кода за счет отслеживания конфликтов при интеграции кода разными разработчиками и возможности организовать резервное копирование. Кроме того, репозитории позволяют организовать удобным способом процесс code review на проектах.
Это удобно и в некоторых случаях безопасней традиционных способов хранения информации, но это не просто смена одного файлового менеджера на другой. Это скорее о процессах разработки: они должны быть цельными. Замена одного кирпича может стать причиной кривизны всей стены. Но цена эксперимента не высока, а результаты обратимы.
2. Как можно наименее болезненно приучить новичков к системе?
Собственным примером.
Не думаю, что нужно ставить себе такую цель — переучить кого-то безболезненно. Цель должна быть в том, чтобы полностью и безоговорочно перейти на этот способ работы. Понятно, что тем, кто привык все делать бегом и в формате «а давай сразу на бою поправим», поначалу будет трудно, потому как работа с репозиториями предполагает много дополнительных действий. Но со временем приобретается автоматизм, примерно как с КПП в автомобиле.
Можно разработать вспомогательные материалы для новичков, в которых описаны на примерах преимущества использования систем контроля версий. Также в системе обучения новичков процесс code review следует строить с использованием системы контроля версий, т.е. новичку с первых дней показывать, что система контроля версий — это стандарт индустрии.
Не должно остаться способов работать по старому регламенту. Ни для «совсем мелких» задач, ни для «крайне срочных» задач. Если не будет технической возможности работать с файлами напрямую, то придется эти правила выполнять. Конечно, сперва необходимо решить вопрос, как быть со старым наследием проектов, иначе будет постоянный соблазн сделать по-привычному.
3. Как обеспечивать безопасность хранения своего кода в чужих «облаках»? Что можно предпринять для усиления безопасности?
Использовать двухфакторную авторизацию. Если вы параноик, установите open source решение для хостинга кода на свой сервер и берите ответственность за безопасность в свои руки!
Рекомендации стандартные — соблюдать политику безопасности паролей, хранить резервные копии и сами продукты в разных местах, в особо серьёзных случаях — применять шифрование канала от «облака» до конечных разработчиков с помощью VPN.
В вопросе безопасности главное — выбрать проверенное «облако», использовать сложные пароли и ssl-подключение.
Все рекомендации прописаны в правилах пользования сервисами или программами. Не ленитесь их выполнять — основной мой совет. До сих пор в практике случается встречаться с паролями «123456».
4. Какие преимущества от continuous integration и continuous delivery, в каком виде, и какие профиты?
Если вы практикуете CI, то уменьшаете этим риск попадания дефектов в продакшн. С continuous delivery уменьшается время доставки готового функционала.
На мой взгляд, преимущества continuous integration можно по-настоящему ощутить только в крупных проектах, которые находятся в постоянном серьезном развитии. Для проекта, где вносится около десятка изменений в год из серии «поменять баннер», внедрение CI будет попросту неоправданно дорогим удовольствием. А вот для проектов, где постоянно происходят масштабные изменения, это так же необходимо, как контроль версий для всей разработки в агентстве. Если говорить конкретно о нашем опыте, то мы применяем CI на всех внутренних проектах компании.
CI позволяет регулярно выполнять ряд действий над исходным кодом проекта: сборку проекта или его разных версий, тесты, статический анализ исходников, деплой билда на удаленный сервер. Регулярность может быть разной: по времени или по событиям, например, в случае появления изменений в исходниках.
Основные преимущества: регулярная проверка исходников и их состояния (достоверности), при этом в случае проблем с исходниками легко найти причину и виновника; автоматизация рутинных действий, получение подробных отчетов о состоянии исходников / проекта.
Типичная ситуация — это рекламное digital-промо. Повышенная ответственность за репутационные и финансовые риски клиента, с одной стороны, и подготовка материалов и уточнение механики до дедлайна, с другой. А данные концепции позволяют тестировать текущее состояние проекта, когда на традиционный этап тестирования мы не имеем достаточно времени.
5. Используются ли репозитории только разработчиками, или другие участники команды тоже должны быть включены в процесс? Если да, то каким образом?
Не должны, но могут, если в этом есть смысл с точки зрения бизнеса. Например, можно использовать систему отслеживания задач для всей организации. Будет совсем здорово, если научите пользоваться системой контроля версий своих копирайтеров.
В полной мере репозитории у нас используются только разработчиками и верстальщиками. Аналитики и дизайнеры агентства, к сожалению, пока используют для работы корпоративный Dropbox по нескольким причинам. Во-первых, репозиторий не дает никакого профита в сравнении версий и совмещении изменений, если речь идет об офисных, а тем более графических программах. Во-вторых, Dropbox намного проще для людей, напрямую не связанных с разработкой. Но конечно, хочется верить, что когда-нибудь полноценные системы контроля версий станут полезны и для них.
Основные пользователи репозитория — это участники производственного процесса, такие как разработчики, дизайнеры, тестировщики, верстальщики, тимлиды, руководители проектов.
Репозиторий может быть доступен и команде заказчика, которая может быть весьма широкой и включать в себя разных специалистов. Типичное использование репозитория со стороны закзачика — это контроль качества и мониторинг состояния.
Формальным пользователем репозитория также могут быть различные автоматизированные системы, например, CI. Такие системы могут выполнять промежуточную сборку и анализ исходных кодов.
В случае если ваш проект является публичным, например, open source, то ваш репозиторий будет открыт всем желающим. Любой разработчик может просмотреть ваш исходный код, может предложить улучшения или запустить свой проект на базе ваших исходников.
Должны, ибо облегчается коммуникация, если все участники процесса понимают правила развития этого процесса. Интерфейс управления репозиторием может предоставить менеджерам много полезной информации о состоянии проекта как для управления командой / проектом, так и для более качественного взаимодействия с клиентом.
6. Хранение и совместное управление репозиториями кода все прочнее входит в жизнь и сильнее внедряется в процесс взаимодействия с управлением проектов и менеджментом. Будет ли продолжаться это объединение процессов и каким образом?
Этим не обязательно будут заниматься все компании. Останутся продукты, предоставляющие только хостинг репозиториев. Также будут и системы «единого окна», с помощью которых можно будет построить процесс разработки, не выходя за рамки одного продукта.
Если говорить про CI, то там эти процессы уже железно объединены, в остальных случаях степень их объединения напрямую зависит от бюджетов проектов. Насколько мы видим, в серьезных агентствах продолжается тренд на повышение качества проектов, и сам инвентарь в этих технологиях процессов постоянно совершенствуется, делая их дешевле. Поэтому, думаю, в скором времени ответ на вопрос, стоит ли использовать continuous integration и continuous delivery, будет так же очевиден, как и в случае с вопросом о контроле версий.
Уже сейчас эти процессы максимально объединены и неразрывны.
Не вижу ничего принципиально нового в подобных сервисах. Да, в каких-то случаях, процесс разработки становится прозрачнее, и процесс управления проектом может идти точнее и гибче. Но совместное управление кодом учитывается в методологиях разработки очень давно.
Рейтинг сервисов-репозиториев для хранения кода 2018 
