Что такое enterprise платформа

Автоматизировать нельзя оставить. Зачем вашей команде Enterprise-приложение

_{Как собрать в прямом эфире 17 000 зрителей? Значит, рецепт такой. Берем 15 актуальных IT-направлений, зовем зарубежных спикеров, дарим подарки за активность в чате, и вуа-ля — крупнейший в Украине и восточной Европе онлайн-ивент готов. Именно так прошла ежегодная мультитул конференция NIXMultiConf.}

Под слоганом «айтишникам — от айтишников» эксперты из Украины, Беларуси, России, Великобритании и Германии поделились опытом и рассказали о новинках индустрии. Полезно было всем — дизайнерам, девелоперам, тестировщикам и менеджерам. И теперь делимся инсайтами с вами.

По мотивам докладов экспертов NIX продолжаем серию статей на самые актуальные темы. На этот раз Business Analyst Наталия Федосеева рассказывает о пользе Enterprise-разработок в командах и делится личным опытом внедрения таких проектов.

Привет! Я — Наталия Федосеева, Business Analyst в NIX c 2015 года. Уже три года занимаюсь Enterprise-проектами в нашей команде. Мы выросли от Excel-таблиц до крупных Enterprise-систем. Оба решения хороши на разных этапах развития команды. Что лучше — решать вам. Я же хочу рассказать, когда Enterprise-приложение может облегчить жизнь, и на что обратить внимание при выборе готовой системы.

Enterprise-проект — это программное обеспечение, которое организация использует для достижения внутренних целей и решения корпоративных задач. Автоматизация бизнес-процессов помогает повысить эффективность работы и обеспечивает функциональную поддержку бизнес-логики.

Рынок Enterprise-решений сформировался из основных нужд компаний:

Несмотря на обширный выбор, огромная доля рынка остается в категории «Другое». Готовые решения по разным причинам одним компаниям не подходят вовсе, а для других — удовлетворяют потребности лишь частично. Все смотрят в сторону трендов Enterprise. Если ваша команда тоже хочет внедрить такой проект, выясните несколько моментов.

Как выбрать «свое» и не переплатить

Перед внедрением любого новшества я рекомендую обратить внимание на:

Более безопасными позиционируются облачные решения. У них уже профессионально организована работа с серверами как со стороны Hardware, так и со стороны Software. Тем не менее, если компания может позволить себе On-premise решения и готова самостоятельно следить за безопасностью, она может быть более спокойна за сохранность своих данных.

В NIX — гибридная система внутренних решений. Относительно несложные бизнес-процессы мы автоматизируем с помощью готовых on-premise систем. Как мы к этому пришли?

Инициатива — валидация — разработка — Enterprise!

Когда-то у нас была маленькая команда и для ведения дел достаточно было таблиц и рассылки на почту. Сегодня все в корне изменилось. От офисных документов мы перешли на полноценные продукты и разработали собственные. Для несложных задач пользовались документами, которые все же требовали время на их поддержание в актуальном состоянии. Какие-то процессы инициативные группы разработчиков потихоньку автоматизировали сами, в свободное от коммерческих задач время. Так появились системы бронирования комнат, девайсов для тестирования, заказа еды.

К хорошему все быстро привыкают. Проекты зажили своей жизнью и стали нуждаться в еще большей поддержке. Когда потребовалась максимальная вовлеченность, мы выделили ответственные команды под каждый проект. Спустя время увидели, что у них возникают похожие проблемы. Поэтому создали комитет, в котором обсуждали архитектурные решения и вырабатывали единый подход, чтобы синхронизировать ведение этих проектов. Для базовых кастомных приложений сформировалась отдельная команда со своим Product Owner. Специалист контролирует все потребности NIX. Например, так произошло с бизнес-процессом букинга комнат для переговоров. Изначально бронирование было «на коленке», потом инициативная команда разработчиков создала функциональное приложение. На момент релиза это было отличное улучшение. Но основной процесс бронирования комнаты был не совсем удобным, и бронь занимала довольно много времени. Позже разработали новое приложение с другими технологиями, которое уже стало частью Enterprise-системы.

Многие налаженные процессы продолжают успешно функционировать и приносить свои плоды, а некоторые еще в процессе становления. Старые решения постепенно отмирают и трансформируются в связи с новыми запросами и возможностями автоматизации. Таким же образом, по мере изменения процессов, выстраиваются и способы их автоматизации.

Каждую инициативу Product Owner оценивает на жизнеспособность. Затем идею обсуждает рабочая группа, выбирается ответственный за принятие окончательного решения. Если команда поддерживает инициативу, идея переходит на стадию предпроектного анализа. Аналитики получают оценки, вырабатывают требования, рассчитывают экономическую эффективность. Последнее — крайне важный момент.

Например, у нас есть шкафчик для хранения девайсов и система, через которую их бронируют. Каждый отмечает, что он взял, вернул или передал девайс другому. Бывает, кто-то не успел записаться или пока дошел до базы, нужную вещь уже перехватили либо устройство оказалось разряжено. От команды поступила инициатива поставить автоматическую систему, которая считывала бы состояние шкафчика — количество девайсов до открытия двери и после. Мы просчитывали экономическую выгоду от автоматизации общей системы слежения за девайсами для тестирования. В итоге поняли, что посадить условную бабушку с журналом было бы гораздо дешевле. Поэтому пока остановились таком варианте: ребята вручную отмечают в системе, что взяли девайс.

Задача бизнес-аналитика — из «пазлов» собрать цельное решение

Большой плюс в создании разработки для своей команды — доступ к стейкхолдерам. Однако их много, и учесть мнение каждого — та еще задача. Способы сбора требований зависят от количества стейкхолдеров. В процессе переработки старой системы мы собирали фокус-группы, с которыми обсуждали подготовленное нами видение новой системы на базе прототипов. Такой подход оказался эффективным. Мы обсуждали конкретный пример, а не просто тратили время на брейншторм. Для себя мы вынесли полезную практику — ходить на такие презентации вдвоем. Пока один аналитик работает с группой, второй — на ходу делает ценные наблюдения «в полях» и тут же фиксирует их.

Когда важно было понять определенные количественные показатели, мы пользовались опросниками. Чтобы выявить тонкости в некоторых бизнес-процессах, наблюдали за деятельностью конечных пользователей. Это очень интересно. Иногда можно заметить инсайты, о которых пользователи не догадались бы рассказать вслух.

В нашем случае самым популярным способом сбора требований оказалось личное интервью. Формат показывает себя наиболее эффективно. Стейкхолдер может высказать требования не только по конкретному вопросу. Любая информация от него может пригодиться в других разработках. И что особенно важно — во время интервью выстраиваются доверительные отношения к команде, а вместе с ними повышается лояльность к продукту.

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

Конечно, можно и микроскопом гвозди забивать. Но лучше делать целесообразные вещи. Фича N сократит затраты времени определенных сотрудников на N часов в неделю — звучит круто. Если мы понимаем, что решение улучшит качество работы и разработка фичи экономически целесообразна, отправляем идею на утверждение. Финальный этап — непосредственно создание продукта. После этого тестируем пробную версию, собираем отзывы стейкхолдеров и постепенно запускаем проект.

В крупной компании для сбора фидбеков подойдет матрица Importance/Influence. Для каждой из подсистем выделяем роли, ключевых представителей и уровень влияния на них определенной системы. Так видим, кого нужно опросить, у кого получить одобрение, кого просто уведомить об изменениях. Все данные наносим на карту.

Оповещения об изменениях высылаем на почту целевой аудитории и передаем новость через лидов. Параллельно обновляем ссылки во всех инструкциях и готовим гайды для пользователей. Документ нужно писать простым языком, чтобы на поиск ответа ушло минимум времени. У нас лучше всего прижились гайды в формате FAQ для несложных процессов и видеозаписи с пошаговой инструкцией для более масштабных.

По своей природе люди как можно дольше хотят сохранять состояние равновесия, поэтому появление новых процессов в команде может вызвать сопротивление или недопонимание. На помощь приходят специалисты User Care. Они отвечают на все вопросы, помогают внести изменения в систему и уладить трудности. Аналитики следят, чтобы User Care знали обо всех обновлениях, что и как работает и в каждом конкретном случае помогут разобраться.

Так что же лучше: приложение или старая-добрая Excel-таблица? Правильного ответа нет. На разных этапах роста у компаний свои потребности. Одни из них закроют готовые Enterprise-решения, для других — понадобятся специальные разработки. А, может, вовсе не нужно изобретать велосипед, и с задачей справится вездесущий Google Docs. Критично относитесь к идеям, учитывайте финансовые возможности организации и, конечно, автоматизируйте все, что можно автоматизировать.

Источник

Enterprise или SaaS: что выбрать бизнесу

Сперва определимся с терминами:

Software as a Servise: облачная модель размещения ПО. Компания оформляет подписку и подключается через интернет к серверам поставщиков софта. То есть работа осуществляется в облаке и обслуживается провайдером.

В статье будем использовать термины: SaaS и облако.

Enterprise: корпоративное решение, которое разворачивается на собственных серверах компании, покупающей софт у производителя. Работа осуществляется без участия поставщика ПО. Проще говоря, это облако, помещенное в инфраструктуру компании-клиента.

В статье будем использовать термины: Enterprise, In-House, On-premise.

Примеры ПО, у которых есть облачное и Enterprise-решения:

Для того, чтобы понять, какое решение более выгодно для вашего бизнеса, необходимо сравнить SaaS и In-House. Можно провести аналогию с арендой квартиры и покупкой собственного жилья:

Оба варианта предполагают проживание в квартире. Разница в том, что в первом случае это ваша личная квартира, где вы можете самостоятельно сделать ремонт, поставить мебель и вообще делать все, что душе угодно. Во втором случае вы живете на съемной квартире, где действуют свои правила и ограничения согласно договору.

То же работает в отношении облака и On-Premise: вы пользуетесь «арендованным» софтом, находящемся в ответственности провайдера, или приобретаете сервис, где «хозяин» вы сами.

Как это работает с чат-центром

SaaS: сообщения клиентов сперва попадают на серверы WhatsApp, Telegram, Viber и прочих мессенджеров. После этого они попадают на серверы чат-центра. Далее вы подключаетесь через интернет к серверам чат-центра и видите сообщения ваших клиентов. При этом на пути следования данных есть посредники — интернет провайдеры и DNS-сервера.

Enterprise: сообщения клиентов поступают на серверы мессенджеров, откуда попадают напрямую к вам. В этой цепочке отсутствуют посредники, провайдеры и поставщики.

Нужен ли вам In-House?

Существует мнение, что In-House выбирают только крупные государственные и финансовые организации. На самом деле, такой тип подключения пользуется не меньшей популярностью среди сотовых операторов, транспортных и логистических организаций, страховых компаний. Это частные компании с большим числом клиентов и высокой нагрузкой на операторов.

Каждая компания, которая работает с персональными данными клиентов, несет ответственность за личную информацию и попадает под действие закона №152-ФЗ «О персональных данных». Enterprise-решение в таком случае помогает более четко следовать закону, чем SaaS.

Особое значение в пользу корпоративного решения имеют скорость и стабильность. Чем больше сообщений принимает чат-центр, тем больше нагрузка на серверы компании. Отсюда низкая скорость переписки. Для того, чтобы операторы могли общаться с клиентами без задержек, необходимо поддерживать высокую производительность системы. Такую возможность предлагает On-Premise.

Преимущества Enterprise

1. Безопасность информации

Для любой компании важно, чтобы личные данные клиентов и конфиденциальная информация не ушли на сторону. Поэтому большое значение придается цифровой безопасности.

1.1 Персональные данные

Клиент, общаясь с компанией, зачастую передает свою личную информацию: реквизиты банковских карт, паспортные данные, номер телефона — конфиденциальную информацию, которая не должна попасть в руки третьих лиц. In-House решение позволит хранить всю информацию на своих серверах, что исключает утечку личных данных.

1.2 Данные компании

Бухгалтерия, базы данных, документация и сведения о компании тоже являются конфиденциальными данными, требующие повышенной защиты от лишних глаз. On-premise подразумевает, что все это хранится на серверах компании, доступ к которым есть только у сотрудников организации.

Закон 152-ФЗ «О персональных данных» гласит:

«Операторы и иные лица, получившие доступ к персональным данным, обязаны не раскрывать третьим лицам и не распространять персональные данные без согласия субъекта персональных данных, если иное не предусмотрено федеральным законом»

Несоблюдение закона влечет за собой гражданскую, административную и уголовную ответственность. Это значит, что компания, допустившая утечку конфиденциальной информации, оплатит штраф или лишится лицензии на свою деятельность.

Chat2Desk оснащен системой безопасности, которая предоставляет доступ только тем, кто авторизовался в системе. Вся информация зашифрована, а значит, даже если произойдет взлом или утечка, то расшифровать данные смогут только какие-нибудь спецслужбы. В отличие от SaaS, In-House исключает посредника между клиентом и компанией, поэтому безопасность такого решения выше. Поэтому компании со статусом оператора персональных данных будет проще следовать закону. Но тогда владелец Enterprise берет ответственность на себя и самостоятельно внедряет систему мониторинга защиты данных.

2. Стабильность и скорость

Доступ к облаку обеспечивается интернет-провайдерами. Компании обеспечивают постоянную работу сервиса за счет мощностей своих серверов и поставщиков интернета. Но это не исключает возможных сбоев в работе, на которые вы не сможете повлиять.

При подключении In-House вы самостоятельно находите провайдеров и ответственность за работу интернета переходит под ваш личный контроль. Теперь любые возникшие трудности решаете вы сами.

Но если вы используете In-House-решение Chat2Desk для внутренней работы отделов, то никакие сбои и задержки вам не страшны. Внутри одной локальной сети документы и сообщения передаются без проблем.

Например: ваш офис расположен на Кипре, а облако Chat2Desk развернуто на российских и европейских серверах. В таком случае вы можете столкнуться с низкой скоростью доставки сообщений и сбоями в работе сервиса. Размещение On-Premise решает эту проблему: работа сервиса не будет зависеть от сторонних посредников и вы сможете свободно общаться внутри компании.

3. Кастомизация софта

Если речь идет о доработках внутри сервиса, то облако имеет ограничения. Каждый провайдер софта имеет roadmap, где запланированы обновления и доработки. Если ваша идея попадает в область roadmap, то вы поймали удачу за хвост – предложение рано или поздно реализуется. Но если ваше предложение идет вразрез с планами сервиса, то придется доплачивать, чтобы софт сделали под потребности вашего бизнеса.

In-House-решение дает возможность самостоятельно кастомизировать и адаптировать софт под ваши нужды. Открытый API позволяет разработчикам вашей компании вносить изменения, проводить дополнительные интеграции со сторонними облачными сервисами, искусственным интеллектом, системами безопасности и собственными чат-ботами, независимо от создателей софта.

Кроме функциональной части вы можете изменить внешний вид интерфейса, например, разместить в углу экрана логотип компании. Настройте виджет на сайте компании: разработайте свой дизайн, а вместо Chat2Desk укажите название компании.

4. Производительность

При работе с SaaS подключаются две стороны — компания и клиенты. Работа и общение проходят внутри облака, ресурсы и возможности которого достаточно широки, однако имеют свои ограничения. Например, в случае высокой нагрузки возможны сбои и задержки в работе софта. Скорость будет на низком уровне до тех пор, пока владельцы сервиса не повысят мощности.

В случае с In-House ситуация меняется: вы сможете самостоятельно регулировать мощность сервера и увеличивать ее в особых случаях. Представьте себе ситуацию: вы запускаете рекламу с выгодным предложением. Вы сможете спрогнозировать наплыв клиентов и вероятную нагрузку на сервера и вовремя принять необходимые меры.

Требования для Enterprise

Технические требования рассчитываются индивидуально и зависят от ваших целей и ожиданий. Главные критерии — объем сообщений, число операторов и количество подключенных мессенджеров.

Чтобы развернуть On-Premise на своем сервере, необходимо соблюдение следующих условий:

1. Оборудование:

2. Отдел разработки: чтобы развернуть In-House на серверах, необходимы специалисты с обеих сторон. Однако, если у вас нет своих разработчиков — это не проблема. Chat2Desk готов полностью настроить Enterprise самостоятельно.

3. ПО: не имеет значения, так как универсальные решения Chat2Desk совместимы с любым программным обеспечением.

4. Виртуальные серверы: для расширения вашей инфраструктуры и снижения нагрузки.

Мы предлагаем 3 схемы развертывания In-House:

Минимальная: для 1000-2000 обращений в сутки. Такой тип подходит для первого подключения, чтобы определить нагрузку на сервера.

Средняя: увеличенная производительность и повышенная безопасность.

Максимальная: для хранения больших объемов данных внутри локальных сетей крупных корпораций.

SaaS vs Enterprise

Для подведения итогов рассмотрим и сравним облако и Enterprise-решение.

Почему In-House более выгоден

Итоговая стоимость SaaS-решения складывается из количества операторов, подключенных мессенджеров и дополнительных опций и модулей. Оплата происходит каждый месяц, квартал или год со скидкой. В случае с On-Premise вы покупаете сервис раз и навсегда. Сравним затраты одной кредитной организации на SaaS и аналог Enterprise-решения:

Наглядно видно, что начальный взнос за облако гораздо ниже, чем разовая покупка In-House. Если сравнить затраты в долгосрочном периоде, то SaaS-решение за 5 лет обойдется в 1 800 000 рублей. И, хотя On-Premise-решение изначально требует большого вложения денег, спустя годы такое приобретение окупится. На графике ниже мы наглядно показали, как будут выглядеть суммарные затраты на облако и In-House.

Заключение

Внедрение Enterprise — решение, требующее разового вложения денег, в отличие от SaaS. Необходимо закупить необходимое оборудование, привлечь разработчиков, внедрить инфраструктуру. Но так вы можете быть спокойным за безопасность ваших данных, контролировать скорость и мощность работы, кастомизировать сервис под свои задачи. К тому же внедрение чат-центра сократит расходы на другие бизнес-процессы.

Определите, какое решение подходит вашему бизнесу и действуйте. Вам нужна помощь? Напишите Chat2Desk через виджет в углу экрана и мы обязательно вас проконсультируем.

Источник

Выбираем редакцию
«1С-Битрикс». Каким проектам подойдет Enterprise

25 минут на чтение

Сравнение способов разработки сайта

Преимущества разработки на готовых платформах мы уже описывали ранее в статье. Обобщим выводы применительно к крупным проектам.

Создание самописной CMS — это долго, дорого и непредсказуемо. Такой подход требует высокой квалификации технического руководителя, при этом есть риск получить результат низкого качества, а стоимость разработки всегда будет дороже, чем покупка готовой системы для управления сайтом. Для разработки собственной платформы придется пару лет содержать штат программистов, а значит сумма разработки может перевалить за десятки миллионов рублей.

Кастомизация стандартных редакций — более дешевый, но также рискованный вариант. Возможно, вы сэкономите, но также есть риск получить некачественный результат, а расходы на разработку могут оказаться сопоставимы с приобретением полноценной редакции для крупных проектов. Это не всегда оправдано, а зачастую способно привести к убыткам. Из-за некорректной реализации архитектуры, неправильно выбранного оборудования и способа его эксплуатации повышается риск появления сбоев и снижается производительность. Поэтому при определении требований к разработке проекта важно руководствоваться принципом достаточности: подбирать оптимальные решения и методы внедрения продуктов.

Примером могут служить ситуации, когда для создания веб-проекта приобретается редакция «1С-Битрикс: Управление сайтом — Бизнес», а затем дорабатываются нужные функции. Для малого и среднего бизнеса с невысокими требованиями к нагрузкам предназначены «1С-Битрикс: Управление сайтом» в редакциях «Малый Бизнес», «Бизнес» и «1С-Битрикс24» в редакции «Корпоративный портал». Для крупных проектов разработана редакция «Энтерпрайз», которая доступна для двух продуктов: системы управления сайтами «1С-Битрикс» и корпоративного портала «Битрикс24».

Источник

Энтерпрайз разработка с нуля

На днях у меня появилась довольно интересная идея для статьи, основанная на следующей предпосылке: на Хабре ни разу не рассказывали об организации энтерпрайз разработки «от и до». В плане совсем с нуля и хотя бы до комфортного минимума. За отправную точку я буду брать ситуацию полнейшего хаоса, когда какой-то код существует на машине единственного разработчика, нет системы контроля версий, нет тестовых сред, код объектов БД существует только внутри эталонной продуктивной базы данных, нет никаких процессов сборки и установки, контроля качества кода и так далее. Возможно читатель задастся вопросом «Такое бывает в 2020 году? Разве кто-то еще так разрабатывает?» и будете только отчасти правы. Предлагаю обсудить детали под катом.

Мне пришло в голову как минимум три возможных сценария:

Примечание: за свои 10+ лет опыта в разработке я сталкивался с каждым из сценариев (на прошлых местах работы).

То есть мы с вами сейчас попробуем набросать план превращения некоторой энтерпрайз разработки с околонулевой организацией процессов и поддержкой инструментов в довольно комфортную и современную. В меньшей степени статья будет касаться стартапов и геймдев студий, поскольку там свои правила и особенности. Хотя бывают и исключения, я вспомню про стартапы в главе про дистрибутивы.

Начало начал — git

Итак, предположим вы попали в одну из трех гипотетических ситуаций, перечисленных мной во вступлении. С чего начать? Конечно с git. Это стандарт индустрии, самая распространенная система контроля версий, лучший инструмент организации разработки из базовых и необходмых. Просто установите его на свою машину, зайдите в папку проекта и наберите последовательно эти команды:

С этого момента у вас теперь будет идти летоисчисление. С этого момента всегда будет предельно однозначен ответ на вопрос «когда и какие были сделаны изменения в коде». Теперь можно делать точечные коммиты отдельных по смыслу правок, можно откатывать их и возвращаться к любому моменту в истории, можно экспериментировать в отдельной ветке и так далее. Даже на одной единственной машине безо всякой синхронизации git уже открывает уйму возможностей.

Работа в команде — GitLab

Что делать, если в команде более одного разработчика? Все в порядке, git был создан в том числе и для командной работы. И если еще 5-7 лет назад следующим я бы порекомендовал установить и настроить git на сервер, то теперь есть GitLab. GitLab это превосходный пример OpenSource проекта, получившего повсеместное распространение и признание в индустрии.

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для git с собственной вики, системой отслеживания ошибок, CI/CD пайплайном и другими функциями.

Вы можете просто взять дистрибутив GitLab и развернуть его внутри корпоративной приватной сети — получится свой маленький «карманный» GitHub. У GitLab есть платные корпоративные версии, можете изучить список доступных фич здесь. Из приятного — платные фичи постепенно перетекают в бесплатные версии.

Итак, GitLab может стать краеугольным камнем организации разработки. Он позволяет оперировать понятием «проект». Проект имеет отдельный git-репозиторий, список задач/дефектов (issues), agile-доску, wiki и т.д. Иначе говоря, из коробки и бесплатно вы получаете практически все инструменты, необходимые для эффективной и распределенной разработки. Но обо всем по порядку.

Хранение кода

Первое и самое главное — GitLab позволяет эффективно и удобно работать над изменениями в коде. Он полностью поддерживает парадигму Github Flow. Это довольно легковесный процесс, при котором каждое новое изменение реализуется в отдельной ветке, а для слияния с основной кодовой базой существуют т.н. запросы на слияние или merge requests (разг. мерджреквест). Последовательность шагов примерно следующая: из задачи по нажатию одной кнопки создается и новая ветка, и одновременно с ней merge request. Далее разработчик переключается на эту ветку, реализует новый функционал или исправляет ошибку, коммитит изменения локально, пушит на сервер. Вся его работа будет максимально удобно отображена на вкладках запроса на слияние: описание, перечень коммитов, построчный дифф. В момент окончания работы над задачей разработчик снимает флаг «work in progress» (WIP). Для тиммейта это может стать сигналом к проведению кодревью. Отдельные замечания можно заводить прямо из диффа, там же можно предлагать свои изменения, и там же можно их сразу принять. Это очень удобный и эффективный способ проведения кодревью. Можно настроить правило: нельзя слить изменения, пока все дискуссии не будут закрыты. В последних версиях можно так же добавить нужных ревьюверов без назначения задачи.

Трекинг задач

Под задачей далее подразумевается некоторая сущность с описанием проблемы/нового функционала/идеи, в рамках которой могут выполняться изменения. GitLab позволяет работать с задачами двумя способами:

и т.д.), вставлять картинки, файлы, смайлы, графики, математические формулы, mermaid-графы и др. Это весело, интересно, модно-молодежно, что помогает поддерживать здоровые отношения в команде!

Можно так же завести шаблоны задач (текстовые файлы в репозитории), например типичный шаблон для ошибки мог бы выглядеть так:

Со временем команда наверняка придет к созданию шаблонов, включающих критерии завершения задачи (definion of done, DoD).

Прочее

Так же в GitLab изначально есть замечательная возможность завести wiki проекта. Лично я воспринимаю вики как способ перенести знания из голов сотрудников в текстовую форму. Благодаря тому, что вики встроена в GitLab, можно прозрачно ссылаться на различные сущности вроде коммитов, задач, пользователей, меток и т.д. Это очень удобно. Так же wiki-странички хранят историю изменений. По ощущениям, они являются обычными Markdown-файлами в выделенном git-репозитории. Так же Wiki можно воспринимать как хранилище документации по проекту. О ведении документов вкратце рассказано в последующих главах.

Майлстоун (milestone) — еще один вид сущностей в GitLab, более высокого уровня чем задачи и merge request’ы. С его помощью можно реализовать организацию последних в осмысленные группы. Примером такой группы может быть поставка (установка новой версии ПО) на определенную дату.

GitLab так же умеет в CI/CD, но вряд ли это понадобится вам сейчас, если еще вчера код хранился на девелоперской машине. Об этом я расскажу в двух словах в отдельной главе.

Крайне рекомендую заводить ко всему README. И самой маленькой утилите, и крупному проекту пригодится README.md. Практика документирования инструкций хоть и отнимает время, но в перспективе экономит гораздо больше. GitLab отлично отображает README как и весь остальной Markdown, позволяет удобно редактировать и коммитить его в прямо в Web-IDE.

Примечание: да, безусловно есть опция вести проект в приватном репозитории на GitHub’е, однако это может противоречить корпоративным стандартам безопасности, есть ограничение на количество таких проектов. Собственное развертывание GitLab’а внутри организации выигрывает по многим статьям.

Миграции БД

Ок, мы разобрались с кодом системы, но что насчет объектов БД, таких как таблицы и хранимые процедуры? Очевидно, что хранение оригиналов скриптов в самой БД рано или поздно приведет к проблемам: либо они «разъедутся» между контурами, либо будет безвозвратно утрачена история, либо еще что-то в таком роде. На помощь придут миграции баз данных. Миграция это переход от одной структуры БД к другой без потери консистентности. Подход к организации миграций ограничен лишь фантазией и смекалкой разработчика, однако известное мне разнообразие подходов может быть классифицировано на:

Если любой из этих подходов применяется не с самого начала разработки, то потребуются подготовительный работы по созданию первоначального снимка. В дальнейшем с каждым подходом довольно удобно работать, но лично мне CREATE-подход импонирует больше.

Хорошая статья по теме: Версионная миграция структуры базы данных: основные подходы.
Особенности миграции базы в случае канареечных релизов: На пути к Canary (там же рассказано про этот тип релизов).

Поставка изменений

Примечание: альтернативный подход описан в главе про Docker.

Итак, у Вас цивилизованно и централизованно хранится код. Но что насчет выкладки нового функционала для конечных пользователей? Способ доставки может отличаться. Например, в случае внутрикорпоративного толстого клиента (а-ля АРМ) это может быть выкладка установочного пакета в сетевую папку, а в случае сайта архив со скриптами. Важно ввести понятие дистрибутива — полноценного комплекта ПО, пригодного для распространения. Важно, что дистрибутив не должен содержать контурозависимых настроек и специфичных конфигурационных файлов. Вы должны иметь возможность «раскатать» однажды собранный дистрибутив на любой контур, и одной этой установкой сразу довести систему до зафиксированной в дистрибутиве версии, включая миграции БД, о которых мы говорили ранее.

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

Продолжим тему билдсервера. На нем должно быть установлено идеальное окружение, необходимый набор инструментов и настроек, позволяющих превратить исходный код в конечный дистрибутив. Шаги, правила и команды сборки обычно настраиваются в ПО класса Jenkins, GitLab или TeamCity. В узком смысле их можно назвать системой сборки. На билдсервер нужно будет установить специальный агент, позволяющий ему взаимодействовать с системой сборки. Результатом прохождения шагов сборки обычно является т.н. артефакт (или несколько артефактов), примером такого артефакта может быть дистрибутив. Имеет смысл хранить артефакты сборки вне системы сборки, например в Nexus/Artifactory. Это поможет решить вопрос надежного хранения всех версий сборок систем.

Версия системы

В главе про поставку изменений хочу дополнительно затронуть понятие версии системы. Формат версии может быть любым:

Правило: ПО получает уникальный последовательный номер версии при сборке. В TeamCity, например, есть специальный build counter, автоматически инкрементирующийся счетчик, который идеально подходит для присвоения уникальных номеров. Из правила следует что:

Дополнительно отмечу, что не стоит вводить отдельные версии для БД, серверной части, толстого клиента и т.д. Наоборот, все компоненты системы, находящиеся в дистрибутиве, должны иметь единый сквозной номер версии. Такой подход поможет при установке обновлений системы, заведении ошибок и регистрации инцидентов.

Автоматическое развертывание

Итак, теперь у вас создаются дистрибутивы: по кнопке или автоматически при слиянии в master-ветку. Можно, конечно, устанавливать их на целевые контура и вручную, но дальновиднее будет настроить автоматическую установку. Фактически это некоторый набор инструкций и команд, выполняющихся последовательно. При этом важно помнить, что некоторые команды требуют параметризации под целевой контур (поскольку дистрибутив контуронезависимый). Реализовать такое с помощью TeamCity, GitLab или даже python-скриптами. Я же рассмотрю кейс использования Ansible/AWX.

Процитирую одну из статей об Ansible на Хабре:

Ansible — это программное решение для удаленного управления конфигурациями. Оно позволяет настраивать удаленные машины. Главное его отличие от других подобных систем в том, что Ansible использует существующую инфраструктуру SSH, в то время как другие (chef, puppet, и пр.) требуют установки специального PKI-окружения.

Важно, что Ansible позволяет проигрывать некоторые сценарии на удаленном хосте. Типичный сценарий автоустановки может включать скачивание дистрибутива, распаковку, остановку сервиса, параметризацию конфигурационных файлов, копирование файлов, запуск миграций БД, перезапуск сервиса. Контурозависимые переменные можно организовать с помощью inventories, заведя по одному инвентори на каждый контур.

Менеджер пакетов

Небольшое дополнение к теме билдсервера: для внешних подключаемых модулей и библиотек удобно пользоваться менеджером пакетов. Например pip для Python, nuget для C#, npm для Node.JS. Конфигурации менеджеров пакетов следует хранить в системе контроля версий вместе с основным кодом системы. В шаги сборки на билдсервере следует включить шаги по восстановлению и загрузке пакетов в соответствии с конфигурационным файлом/файлами. Так же это облегчит приход нового разработчика в команду — ему не нужно будет специальном образом настраивать свое рабочее окружение, обо всем позаботится менеджер пакетов. Единственный минус — некоторые экземпляры грешат тяжеловесностью, но с этим мало что можно поделать, пользы они все-таки приносят больше.

Тестовые среды

Примечание: альтернативный подход описан в главе про Docker.

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

Стандартом индустрии является наличие трех контуров:

Часто нужны отдельные контура для нагрузочного тестирования, опытной эксплутации, симуляционного тестирования, гостевого внешнего тестирования. В идеале каждый контур повторяет продуктивный по своим характеристикам, но имеет соответствующие среде настройки и интеграции. Управлять этим вручную довольно трудно, поэтому рекомендую использовать инструменты вроде Ansible (читайте далее), chef и др.

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

Наиболее простым способ организации тестовых контуров являются виртуальные машины. Однажды настроенный образ может клонироваться произвольное количество раз. Это не совсем моя сфера, поэтому я не могу здесь подсказать, однако идея в целом достаточно интуитивная: «нарезать» виртуалок сильно проще, чем каждый раз настраивать железный сервачок.

Автотесты

Я намеренно не стал касаться темы unit-тестов, потому что в статье рассматривается сценарий превращения гадкого утенка в лебедя. По моему опыту неожиданное внедрение unit-тестов в проект без культуры написания тестируемого кода не принесет никаких легких побед. Напротив, создание автотестов, и неких автоматизированных сценариев проверки, поможет в короткие сроки сократить объемы ручного труда разработчиков и тестировщиков. Не могу посоветовать конкретный софт, все находится в руках QA-инженеров и разработчиков.

Эксплуатация

Существует подход к промышленной эксплуатации системы, при котором команда разработки не принимает непосредственное участие в процессе, поскольку для этого выделена отдельная команда сопровождения. Подобное разделение может быть даже зафиксировано в нормативных документах организации. В этом случае следует с особенным вниманием отнестись к теме организации логгирования и мониторинга.

Логгирование

Рано или поздно появится необходимость технологичнее управлять логами. Вероятно, логгирование в каком-то виде присутствует в коде системы. Например, пишется в файл или стандартный вывод. Возможно даже настроена ротация файлов (например, на предмет достижения максимального размера файла), и старые файлы упаковываются в архив. Пожалуй, главная проблема такого подхода заключается в том, что файлы физически находятся в конкретной среде (контуре), и разработчику их как-то нужно оттуда вытаскивать. Поиск по истории осложнен, обработка большого объема логов так же осложнена. Эти и другие сопутствующие проблемы могут быть решены с помощью специального ПО управления логами.

Наиболее известные представители — ELK-стек и Graylog. Основной сценарий использования подразумевает разворачивание подобной системы внутри организации и дальнейшую отправку в нее логов из приложений и систем. Как правило отправка происходит по UDP, чтобы не нарушать работу приложений в случае отказа системы логгирования. В Graylog есть возможность воспользоваться т.н. стримами — онлайн-обработчами потока, которые применяются к логам сразу на входе в систему управления логами. Как пример: можно завести отдельный стрим на каждый контур.

Мониторинг

Из бесплатного ПО для решения задач мониторинга я бы посоветовал Grafana. Позаимствовал список особенностей Grafana из статьи:

Отличный софт, чтобы оценить удобство и красоту стоит хотя бы раз воспользоваться.

Контроль качества кода

В поддержании кодовой базы в «здоровом» состоянии кроется секрет многих успешных проектов. Роберт Мартин в своих лекциях рассказывает о том, что в разработке не так важно ускоряться, как не замедляться. Сохранение высокого темпа внесения изменений возможно не только благодаря хорошей архитектуре, но и постоянному рефакторингу, поэтапному улучшению кода, сокращению технического долга. Автоматизированные средства не сделают всю работу за вас, но сильно помогут в поддержании кодовой базы в хорошем состоянии.

Sonarqube

Проведение кодревью помогает держать кодовую базу в чистоте и порядке. Однако просмотреть весь существующий код на предмет ошибок и недостатков обычно не представляется возможным — это займет слишком много времени. Статические анализаторы кода помогут выполнить эту задачу с должным уровнем качества и практически без усилий. Рекомендую обратить внимание на бесплатный инструмент SonarQube:

SonarQube — платформа с открытым исходным кодом для непрерывного анализа (англ. continuous inspection) и измерения качества программного кода.

Однажды настроенный сонар может выполнять регулярные проверки качества кода в разрезе ошибок, технического долга, информационной безопасности и кода «с душком» (code smells).

Как можете видеть на скриншоте, по итогам проверки выводится полный отчет с итоговой оценкой по каждому критерию. Поддерживаются все основные языки, существуют продвинутые платные плагины.

Стиль кодирования

Практика фиксации единого стиля кодирования присуша многим сформировавшимся командам. Code guide, code style — это все примерно об одном и том же. Открывать ли фигурные скобки для одного выражения в if, переносить ли на новую строку каждый параметр функции, табы или пробелы — все эти необднозначности помогает решить договоренность команды о едином стиле кодирования. Единообразная кодовая база позволяет не только облегчить чтение кода участниками команды, но и понизить планку вхождения в проект новичкам.

Линтеры — специальный класс программ, который может помочь в неуклонном соблюдении стиля кодирования. Историческая справка: Lint это имя собственное статического анализатора языка C, «который сообщал о подозрительных или непереносимых на другие платформы выражениях». Его название стало именем нарицательным для всех программ такого рода. Сейчас линтеры существует для большинства известных языков программирования: в виде отдельных утилит, плагинов для редакторов или фичей IDE. Стиль кодирования задается некоторым конфигурационным файлом, который распространяется в команде.

Безопасность

Тема информационной безопасности была кратко затронута в главе по SonarQube. Существуют и более продвинутые статические анализаторы кода на предмет уязвимостей, например ChechMarx. Это гибкое и настраиваное ПО поддерживает все основные языки программирования и виды уязвимостей. Механизм работы примерно следующий: в коде программы отслеживается поток данных из всех входных точек (пользовательский ввод, аргументы командной строки, данные из БД) в выходные (UI, отчеты, БД) на предмет отсутствия санитайзеров. Санитайзером называется любая функция или метод, проверяющий содержимое ввода на легитимность. Если санитайзер отсутствует, то анализатор сообщает о потенциальной уязвимости. ChechMarx так же приводит полную пошаговую цепочку преобразований данных, допускающую возможную уязвимость.

Бесплатное ПО из этой же категории: wapiti, nikto

Общее неинструментальное

Большинство рекомендаций это статьи затрагивают применение специализированного ПО для улучшения того или иного аспекта процессов разработки. Однако значимая доля задач построения эффективной разработки решается не использованием софта, а применением методологий, организацией процессов и принятием соглашений о процессе.

Методология разработки

Использование методологий разработки помогает сделать коллективную разработку организованной. Если ранее не использовалась вообще никакая методология, то стоит задуматься об адаптации какой-либо из них. Есть большое количество статей по теме, которые помогут определиться. Мне понравились эти две: issoft.by и geekbrains.ru.

В статье в основном факты, но в этом абзаце разбавлю материал субъективным мнением. На практике в энтерпрайзе чаще всего можно встретить водопад и различные модификации agile. Первый традиционно хаят, а второй восхваляют 🙂 На практике и водопад может быть достаточно удобен, если обогатить его обратной связью на каждом этапе. И, например, крупные законодательные правки с фиксированной датой вступления в силу, затрагивающие сразу нескольких систем организации, проще оркестрировать в водопаде. С другой стороны, новые самостоятельные проекты бывает удобнее делать в режиме гибкой разработки, особенно если бизнес принимает в них активное участие.

Релизы

Планировать нагрузку на команду и управлять ожиданиями заказчика помогут релизы — приуроченные к конкретной дате изменения в ПО. Релиз можно считать кроссистемной версией, инструментом оркестрирования разработки между несколькими самостоятельными системами.

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

Примечание: в GitLab есть специальная сущность — Release, однако для планирования релизов в agile-режиме можно использовать и Milestone’ы. Рекомендую изучить обе функциональности.

Документация

Ведение документации достаточно древняя практика, сопровождающая разработку. Она помогает создать общее информационное пространство проекта, позволяет участникам команды говорить «на одном языке» и облегчает погружение новых членов команды. В плане организации процесса есть опции:

Желательно определиться с подходом «на берегу», так как описать зрелую или легаси систему с нуля может быть довольно трудно (и нужно ли, если проект успешно обходился без нее?). Самое главное свойство документации — она должна приносить пользу.

Физически документацию можно вести рядом с кодом системы в git-репозитории (например, в MarkDown), в задачах багтрекера/agile-доски (GitLab, Jira, Redmine), в специально выделенной цiki (GitLab, Confluence), в Word-документах (в т.ч. с использованием sharepoint) и т.д. Важно иметь возможность просматривать историю изменения документации, чтобы можно было заглянуть в любой момент из прошлого проекта.

Что дальше?

К этому моменту процесс разработки уже нельзя назвать хаотичным: ведется история изменения кода, есть культура написания документации, организован процесс поставок изменений на целевые среды, настроено логиррование и мониторинг. Однако это только базовая организация, всегда есть куда расти. Поэтому далее рекомендую присмотреться к более продвинутым темам: CI/CD & DevOps и Docker & K8s.

CI/CD & DevOps

Простыми словами, CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчики, аналитики, инженеры качества, конечные пользователи). Принцип действия в чем-то похож на конвейер: методика выполняет интеграционную функцию, объеденяет перечисленные ранее процессы в единую цепочку, цель которого — доставка готового продукта конечному пользователю.

Важно: полноценные CI/CD в энтерпрайзе не все могут себе позволить. Ограничения могут быть связаны с неготовностью бизнеса, требованиями законодательства и регуляторов, незрелостью инструментариев, отсутствием компетенций. Проще говоря, слияние кода в мастер (пусть даже с автоматическим прохождением тестов и прочими проверками) это совсем не повод для установки в продуктив.

DevOps (Development Operation) – это набор практик для повышения эффективности процессов разработки и эксплуатации программного обеспечения за счет непрерывной интеграции и активного взаимодействия профильных специалистов с помощью инструментов автоматизации. Методология предназначена для эффективной организации процессов создания и обновления ПО и услуг.

Специалистов по настройке CI/CI называют DevOps инженерами или просто DevOps’ами.

Docker & K8s

Контейнеры (Docker в частности) это большая тема, попробую покрыть её в двух словах и приправить ссылками (на Хабре много качественных материалов по теме).

Краткая шпаргалка

Для простоты контейнер можно считать облегченной виртуальной машиной без накладных расходов на гостевую ОС, так сказать, песочницей для процесса. Контейнеры позволяют запускать изолированные друг от друга процессы в идеальном окружении на одной и той же хостовой ОС без конфликтов зависимостей. Можно начать изучение темы со статьи такого плана.

Сами по себе контейнеры уже были прорывом, однако засияли они в момент появления зрелых средств оркестрации, таких как Kubernetes. В плане разработки контейнеры предоставляют больше преимуществ для небольших сервисов (aka микросервисов) нежели монолитов. Да, придется затронуть тему микросервисов, чтобы понять преимущества докера и оркестрации контейнеров. Поверхностное сравнение архитектур:

Подход микросервисной архитектуры требует подходящего инструментария, такого как тандем Docker и Kubernetes. Docker обеспечивает:

Kubernetes в свою очередь обеспечивает:

Практическое использование

Заключение

Спасибо за внимание! Буду рад дополнениям и предложениям.

Источник