Что такое интеграция цикла
Интеграция программного обеспечения. Описание процесса от бизнес консультанта
Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность. Википедия.
В процессе работы бизнес консультантом, для увеличения эффективности работы систем предприятия, я почти всегда предлагаю провести интеграцию между различным ПО заказчика. Потому что интегрировав различные системы возможно добиться эффекта синергии. Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем. Интеграция – это очень важная часть работы по автоматизации бизнес-процессов, так как требуется она постоянно. В разных ситуациях возникает потребность оперативно обмениваться данными между различными конфигурациями 1С, между программными продуктами 1С и сайтом, между 1С и CAD системами, а также системами биллинга и т.д. Также достаточно часто требуется интегрировать между собой различные веб сервисы, например, интернет-магазин и CRM-систему. В общем, объединить работу различных подразделений компании и автоматизировать рабочий процесс без использования интеграции в большинстве случаев невозможно.
Что такое интеграция?
Википедия дает нам такое определение:
Интегра́ция (от лат. integratio — «соединение») — процесс объединения частей в целое. В зависимости от контекста может подразумеваться: Веб-интеграция — объединение разнородных веб-приложений и систем в единую среду на базе веб. Интеграция данных — объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде.
Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением: Интеграция программных систем и продуктов — это обмен данными между системами с возможной последующей их обработкой. Смысл интеграции заключается в том, чтобы данные, которые пользователь вводит в одну систему, автоматически переносились в другую. Продукт, в который пользователь вводит данные, называется источник. А получатель данных, соответственно, приемник. Достаточно часто данные переносят в обе стороны, например, после преобразования в системе-приемнике результаты отправляются обратно в источник. А потому интеграция бывает как односторонней, так и двухсторонней. Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам. Лично я делю процесс интеграции на такие этапы:
Я всегда придерживаюсь этой последовательности при планировании работ по интеграции. Это помогает работать системно, не упустить ни одного важного момента и провести интеграцию таким образом, чтобы клиенту было удобно работать в объединенной системе. Важно: при интеграции различных программных решений нужно хорошо понимать их функционал. Когда-то я и сам совершал такую ошибку, и брался за интеграцию программных продуктов, которые я недостаточно хорошо знал. А потому могу сказать точно: изучать программный продукт в процессе интеграции – это не совсем корректно. При таком подходе чаще всего возникает множество ошибок и проблем, например, перенос не тех данных или сбои в работе. Рекомендую сначала хорошо изучить программный продукт, понять, что он может, каким образом в нем реализованы те или иные функции, и только потом заниматься интеграцией. В принципе, в процессе интеграции вам может потребоваться и более сложный обмен, и придется вводить, например, трех- или четырехстороннюю интеграцию. Но, по сути, эти процессы ничем не отличаются от обычного одно- или двухстороннего процесса. А потому я буду говорить об интеграции односторонней. А в конце скажу пару слов об особенностях двухсторонней. Все остальные направления вы всегда сможете выстроить по аналогии.
Выбираем источник и приемник
Для каждого случая интеграции данных важно четко определить, какая система будет источником, а какая – приемником. Например, у вас есть система CRM и программа 1С: Торговля. В обеих системах существует такое понятие, как контактное лицо. В принципе, вводить его вы можете и с одной, и с другой стороны. В данном случае, очевидно, что источником стоит назначить CRM, так как этого требует логика работы с любой CRM-системой. Аналогично и в других случаях. Нужно понимать, в какой системе пользователь будет вводить данные, а какая станет получателем этих данных через интеграцию. Это обязательно согласовывается с клиентом (пользователем), кроме случаев, когда источник очевиден. при этом обязательно нужно поставить в известность клиента, что данные определенного типа следует вводить именно через систему-источник.
Сопоставление объектов (данных)
Каждый раз при работе с данными нужно очень хорошо понимать, что именно вы выгружаете, в каком виде, а также, куда вы будете выгружать эти данные. В некоторых случаях в источнике у вас будет строковая переменная, а в приемнике – два или более объектов. В других важно просто правильно выбрать объект-приемник. Например, практически в любой CRM контактное лицо и клиент – это одно и то же. С другой стороны в 1С контактное лицо может быть клиентом, партнером, поставщиком. И очень важно понимать, куда именно записывать данные этого контактного лица. Также важно сопоставлять все данные до того, как начнется работа непосредственно с кодом. Для этого прекрасно подойдут таблицы или блок-схемы. Когда-то я так же, как и многие, пренебрегал этим этапом работы. Сейчас я знаю, что эти действия позволят избежать огромного количества ошибок. На какой бы стороне ни работал программист – на стороне программы-источника или приемника, такая табличка очень помогает в работе. Программист должен четко понимать, какие данные будут брать из источника, куда их нужно переносить, и как они будут обрабатываться. Например, при выгрузке контактного лица из CRM нужно четко сопоставить этот контакт партнеру или покупателю. Также очень важно понимать, какие преобразования потребуются для выгружаемых данных. Например, нужные для интеграции данные в источнике хранятся в качестве перечисления в виде текста. А в приемнике (пусть это будет 1С) аналогичное перечисление имеет ссылочный тип. Следовательно, вам потребуется преобразовать текст в ссылку, и уже ссылку передать в документ. И здесь возникает проблема: требуются правила сопоставления. Вы должны четко продумать и прописать правила сопоставления. Более того, об этих правилах необходимо оповестить ваших клиентов. Важно понимать, что клиент не видит логику работы обмена данными, он не понимает особенностей интеграции. Конечно, вы обязательно введете ограничение прав доступа, добавите другие варианты защиты. Но, как показывает практика, это не гарантирует от того, что пользователь совершит ошибку, из-за которой интеграция перестанет работать или будет работать не корректно. Это может быть кто-то из сотрудников, обладающий правами администратора, или приглашенный специалист, который дорабатывает, например, печатную форму документа, но при этом не осведомлен об особенностях интеграции. В результате возникают самые разные казусы. Например, вы используете в качестве ключевого слова для поиска при сопоставлении слово «дилер». Клиент по каким-то причинам меняет его в программе-источнике на слово «дилеры». Казалось бы, мелочь! Но эта мелочь приведет к тому, что поиск в 1С перестанет работать. Я решил эту проблему таким образом:
Почему я пришел к такому варианту работы? Интеграция – процесс сложный, и проблемы из-за человеческого фактора возникают достаточно часто, защититься от них практически не реально. Также бывают и программные сбои, особенно это касается таких сложных систем с большим числом багов, как программные продукты 1С. А для бизнеса очень важно, чтобы обмен данными проходил своевременно, а если возникла проблема также важно ее оперативно устранить. Например, в моей практике была ситуация, когда я провел интеграцию 1С и Oracle, причем, последний являлся программой-источником. Далее на стороне Oracle изменили одно из полей. В результате заказы перестали загружаться в 1С вообще, при этом сервер не выдавал уведомление об ошибке. Обнаружили проблему через неделю. С одной стороны, это явная недоработка отдела продаж моего клиента, так как неделю не получать ни одного заказа и не волноваться по этому поводу, мягко говоря, странно. С другой – отсутствие уведомления об ошибке я считаю собственной недоработкой. Конечно, в результате ошибки были исправлены, система дальше работала без сбоев, но теперь я всегда добавляю несколько вариантов уведомления об ошибке при передаче данных. Самые распространенные решения:
В некоторых случаях также стоит добавлять уведомление о сбое другим лицам, этот вопрос решается с заказчиком индивидуально. Также стоит лог-файл ошибок вести максимально подробно и как можно дольше хранить историю. Не забывайте, что вы имеете дело с данными, которые имеются в одной базе данных, но отсутствуют в другой. И без подробного отчета вам будет очень сложно понять, что именно произошло в процессе передачи данных.
Обмен данными: писать самому или применять типовое решение?
Лично я предпочитаю всегда разрабатывать решение под заказчика. Здесь можно спорить, можно обсуждать различные варианты, но есть факт: типовые обмены данными всегда сильно перегружены возможностями, которые вашему клиенту не нужны. В результате процесс обмена значительно замедляется, а число возможных ошибок вырастает в разы. Кроме того, при выборе типового программного решения вы очень сильно зависите от поставщика программного обеспечения. Для любого исправления бага вам придется ждать выпуск очередной версии программы. Также придется подстраиваться при обновлениях под все изменения в работе, который внес разработчик. А потому при выборе между самостоятельным написанием обмена данными и типовым решением, которое не на 100% подходит для данной ситуации, лучше писать обмен самому. В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.
Метод подключения: REST API, SOAP или прямое подключение к базе приемника
Выбор протокола обмена данными в большинстве случаев напрямую зависит от системы, которую вы интегрируете. В большинстве случаев программисту приходится учитывать требования обеих систем, а потому выбора как такового не существует. В тех случаях, когда система может работать с несколькими протоколами, выбирайте тот, который вам удобнее. По моему опыту, для малых и средних предприятий этот вопрос не принципиален.
Вопросы клиентского доступа: почему не работает обмен?
Я считаю, что обо всех возможных ограничениях в доступе нужно узнать на начальном этапе интеграции. Таким образом, вы гарантированно избежите очень распространенной проблемы: Вы внедрили интеграцию, все проверили, протестировали, убедились, что система работает. После чего пользователь обнаруживает, что обмен данными не происходит. Самые распространенные ситуации:
В первых двух случаях ограничения обычно связаны с политикой информационной безопасности предприятия, и решаются они на административном уровне. Для пользователей, которым потребуется работа с обменом данных, системный администратор настроит перечисленные вами права. Аналогично для ограничения по IP. В случае работы с CRM-системой ограничения обычно обусловлены оплаченным пакетом услуг. Здесь достаточно оповестить клиента о наличии такого ограничения, и, при необходимости, помочь оплатить и настроить расширенный пакет.
1С идентификаторы и ошибки, связанные с ними
При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных. Если вы будете проводить поиск по всему справочнику с использованием идентификатора, который предназначен для работы внутри определенного типа данных, возникнет ошибка. Объект может быть вообще не найдет, либо система найдет сразу несколько разных объектов. К этой особенности 1С нужно относиться очень внимательно. Еще одна проблема: нет возможности привязаться к уникальному идентификатору. Например, системой-источником является сайт, и на нем не предусмотрено отдельное поле для информации о клиенте, она идет в общем тексте заказа. В этом случае придется выбрать какой-то другой вариант идентификации, например, по email. При интеграции очень важно выбрать в источнике одно из полей, которое и станет уникальным идентификатором. Я считаю хорошим тоном дублирование этого идентификатора в двух системах. Например, если я делаю выгрузку информации из CRM в 1С, то поле-идентификатор из CRM я копирую в систему 1С. В дальнейшем весь поиск и интеграция производится по этому полю быстро и просто. В принципе, это не обязательное действие. Более того, вы будете хранить даже избыточные данные, так как у вас есть нужная информация в одной из систем, но такое дублирование повышает надежность работы обеих программ и является удобным решением для интеграции и последующей обработки данных. Например, по идентификатору, который идентичен источнику, поиск будет производиться проще и быстрее, так как он не будет требовать дополнительной обработки. Кроме того, если что-то случится с базой данных одной из систем, благодаря дублирующимся идентификаторам сопоставить данные будет намного проще.
Формат выгрузки
Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.
Постобработка
Итак, обмен данными прошел успешно. Что дальше? Я считаю, что это еще не финал интеграции, так как пользователю мало того, что данные появились в системе. Обычно ему требуется, чтобы с этими данными выполнялись какие-то действия. Что именно нужно клиенту, следует уточнить у него. Но всегда надо помнить о том, что вы работаете для пользователя, для того, чтобы ему было удобно. Для интернет магазинов при интеграции чаще всего требуются:
Постобработка требуется, прежде всего, для того, чтобы полученные данные прошли полный жизненный цикл, а, следовательно, приняли участие в каких-то последующих бизнес-процессах. А потому после загрузки должны запускаться оповещения или какие-то определенные процессы, например, обработка заказа. Кроме действий, которые нужно выполнить в приемнике, также часто требуется после завершения успешной передачи данных выполнить определенные действия в источнике. Что именно потребуется, вам также расскажет пользователь. Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.
Тестирование интеграции
С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье «Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть III. Финальная».
Отличие односторонней и двусторонней интеграции
На самом деле, принципиальных отличий у односторонней, двусторонней или многосторонней интеграции не существует. Суть процесса остается прежней, просто в разные моменты времени приемник и источник меняются ролями. Единственное важное правило, которое я ввел для себя и вам также советую: при двухстороннем обмене необходимо хранить уникальный идентификатор для всех систем, которые участвуют в интеграции. И я считаю, что его также стоит дублировать в обеих системах. Сегодня я постарался кратко рассказать об особенностях процесса интеграции, с которыми я лично сталкиваюсь на практике. Я надеюсь, что статья оказалась для вас полезной, а если возникнут какие-то вопросы, я, как и всегда, готов на них ответить.
Что такое интеграция и что именно можно интегрировать
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Существует множество терминов, которые мы вставляем к месту и не к месту в свою речь, точно не зная, что они обозначают.
К таковым относится и понятие «интеграция». Разберемся, что определяет этот термин, и в каких сферах применяется.
Понятие «интеграция»
В переводе с латыни «интеграция» это «вставка, соединение». Рассуждая логически, делаем вывод, что «интегрировать», значит, вставлять какую-то часть в единое целое.
А «интегрировать» — это значит объединить, слить (например, компании), переплести, вставить, добавить, соединить и т.п.
Простой пример: собирая пазл, мы интегрируем его фрагменты в единую картинку. Развитие человеческого общества – это тоже череда интеграций и дифференциаций (разделения целого на составные части).
Интегрировать что-то можно двумя путями:
По каким принципам можно интегрировать
Интеграция может происходить, основываясь на нескольких принципах. Рассмотрим основные из них подробней.
Пример международной экономической интеграции горизонтальной модели – Евросоюз: страны имеют единую валюту, решают общие политические и экономические проблемы.
Главная цель объединения на основе диагональной модели – это диверсификация, т. е. распределение инвестирования по нескольким направлениям с целью увеличить прибыль и (или) не допустить краха. Иными словами – «раскладывание яиц по разным корзинам».
Наглядный пример – консорциум (объединение независимых предприятий) «Альфа-Групп». Интегрированные в консорциум предприятия занимаются инвестированием, страхованием (что это такое?), розничной торговлей, водоснабжением, производством и реализацией минеральной воды.
Интеграция в различных сферах
Интеграция – это процесс, который актуален для всех сфер жизни человека.
И примеров тому множество:
Интеграция в экономике
Экономическая интеграция (ЭИ) – сближение (или объединение) предприятий, отраслей и регионов. Если ЭИ выходит за рамки одной страны, то тогда речь идет о международной экономической интеграции (МЭИ).
Это создание взаимовыгодных экономических отношений между государствами. Регулируется соглашениями на международном уровне. Подобное сотрудничество дает участникам ЭИ расширенный доступ к материальным, трудовым и финансовым ресурсам, к новейшим технологиям и рынкам сбыта.
Формы МЭИ представлены на схеме:
Что и как можно интегрировать в политике
Политическая интеграция (ПИ) – сближение деятельности политических единиц (государств, политических партий), целью которого является взаимное сотрудничество для достижения определенных результатов, близких всем членам интеграционного сообщества. ПИ бывает 2 видов:
Интеграция в науке и педагогике
Познание человеком сути вещей и явлений – бесконечный процесс. Чем глубже и точнее научные изыскания, тем очевидней, что полноценное изучение какого-либо объекта не может быть проведено в рамках только одной научной дисциплины.
Биохимия – один из примеров симбиоза двух наук – биологии и химии. Невозможно понять принципы жизнедеятельности биологических организмов без знания химических процессов, происходящих в их клетках и тканях.
Приведем еще примеры: геофизика, биофизика, кибернетика и т. д. Следовательно, интеграция наук – это объединение знаний, накопленных в рамках нескольких научных дисциплин, в единое целое для возможности всестороннего изучения объектов, явлений, процессов.
Стремление понять мир, в котором мы живем, диктует необходимость научной интеграции. И это касается не только точных наук. Например, обществознание – это комплекс дисциплин, изучающих все стороны деятельности человеческого общества:
Интеграция в обществознании – это рассмотрение изучаемого объекта не в рамках какой-либо из перечисленных наук, а в их совокупности.
Удачи вам! До скорых встреч на страницах блога KtoNaNovenkogo.ru
Эта статья относится к рубрикам:
Комментарии и отзывы (2)
Интеграция означает жизнь по чужим правилам, если человек интегрируется в общество, значит он берет на себя обязательство подчиняться общественным законам.
Тоже и в межгосударственных отношениях, когда Россия входит в какие-то международные организации, союзы, то так же берет обязательства, что, на мой взгляд, сильно подрывает суверенитет. Мы начинаем зависеть от внешних навязанных нам правил, вряд ли указания некоего дяди могут благоприятно сказываться на благосостоянии народа.
Игорь: хорошо подмечено. Именно от таких ошибочных интеграций лихих девяностых мы сейчас потихоньку и избавляемся. В том числе, и с помощью летних поправок в конституцию
Что такое CI (Continuous Integration)
CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:
Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
Содержание
Что такое CI
CI — это сборка, деплой и тестирование приложения без участия человека. Сейчас объясню на примере.
Допустим, что у нас есть два разработчика — Маша и Ваня. И тестировщица Катя.
Маша пишет код. Добавляет его в систему контроля версий (от англ. Version Control System, VCS). Это что-то типа дропбокса для кода — место хранения, где сохраняются все изменения и в любой момент можно посмотреть кто, что и когда изменял.
Потом Ваня заканчивает свой кусок функционала. И тоже сохраняет код в VCS.
Собрать билд можно вручную, но это лишний геморрой: нужно помнить, что в каком порядке запустить, какие файлики зависят друг от друга, не ошибиться в команде… Обычно используют специальную программу. Для java это Ant, Maven или Gradle. С помощью сборщика вы один раз настраиваете процесс сборки, а потом запускаете одной командой. Пример запуска для Maven:
Это полуавтоматизация — все равно нужен человек, который введет команду и соберет билд «ручками». Допустим, этим занимаются разработчики. Когда Катя просит билд на тестирование, Ваня обновляет версию из репозитория и собирает билд.
Но собрать билд ≠ получить приложение для тестирования. Его еще надо запустить! Этим занимается сервер приложения. Серверы бывают разные: wildfly, apache, jetty…
Если это wildfly, то нужно:
А вот если убрать из этой схемы человека — мы получим CI!
CI — это приложение, которое позволяет автоматизировать весь процесс. Оно забирает изменения из репозитория с кодом. Само! Тут есть два варианта настройки:
Когда CI получило изменения, оно запускает сборку билда и автотесты.
Если сборка провалилась (тесты упали, или не получилось собрать проект), система пишет электронное письмо всем заинтересованным лицам:
Если сборка прошла успешно, CI разворачивает приложение на тестовой машине. И в итоге Катька может тестировать новую сборку!
Да, разумеется, один раз придется это все настроить — рассказать серверу CI, откуда забирать изменения, какие автотесты запускать, как собирать проект, куда его потом билдить… Но зато один раз настроил — а дальше оно само!
Автотесты тоже придется писать самим, но чтож поделать =)
Если на пальцах, то система CI (Continuous Integration) – это некая программа, которая следит за вашим Source Control, и при появлении там изменений автоматически стягивает их, билдит, гоняет автотесты (конечно, если их пишут).
В случае неудачи она дает об этом знать всем заинтересованным лицам, в первую очередь – последнему коммитеру. (с) habr.com/ru/post/352282
Программы CI
Наиболее популярные — Jenkins и TeamCity.
Но есть куча других вариаций — CruiseControl, CruiseControl.Net, Atlassian Bamboo, Hudson, Microsoft Team Foundation Server.
Как это выглядит
Давайте посмотрим, как это выглядит с точки зрения пользователя. Я покажу на примере системы TeamCity.
Когда я захожу в систему, я вижу все задачи. Задачи бывают разные:
Поэтому, даже если я не подписана на оповещения на электронную почту о состоянии сборок, я легко могу посмотреть, в каком состоянии сейчас система. Открываешь графический интерфейс программы и смотришь.
Как CI устроен
Как и где CI собирает билд и прогоняет автотесты? Я расскажу на примере TeamCity, но другие системы работают примерно также.
Сам TeamCity ничего не собирает. Сборка и прогон автотестов проходят на других машинах, которые называются «агенты»:
«Агент» — это простой компьютер. Железка или виртуальная машина, не суть. Но как этот комьютер понимает, что ему надо сделать?
В TeamCity есть сервер и клиент. Сервер — это то самое приложение, в котором вы потом будете тыкать кнопочки и смотреть красивую картинку «насколько все прошло успешно». Он устанавливается на одну машину.
А приложение-«клиент» устанавливается на машинах-«агентах». И когда мы нажимаем кнопку «Run» на сервере:
Сервер выбирает свободного клиента и передает ему все инструкции: что именно надо сделать. Клиент собирает билд, выполняет автотесты, собирает результат и возвращает серверу: «На, держи, отрисовывай».
Сервер отображает пользователю результат плюс рассылает email всем заинтересованным лицам.
При этом мы всегда видим, на каком конкретно агенте проходила сборка:
И можно самому выбирать, где прогонять автотесты. Потому что бывает, что автотесты падают только на одном билд-агенте. Это значит, что у него что-то не так с конфигурацией.
Допустим, исходно у нас был только один билд-агент — Buran. Название может быть абсолютно любым, его придумывает администратор, когда подключает новую машину к TeamCity как билд-агента.
Мы собирали на нем проект, проводили автотесты — все работало. А потом закупили вторую машинку и назвали Apollo. Вроде настроили также, как Буран, даже операционную систему одинаковую поставили — CentOs 7.
Но запускаем сборку на Apollo — падает. Причем падает странно, не хватает памяти или еще чего-то. Перезапускаем на Apollo — снова падает. Запускаем на Буране — проходит успешно!
Начинаем разбираться и выясняем, что в Apollo забыли про какую-то настройку. Например, не увеличили количество открытых файловых дескриптеров. Исправили, прогнали сборку на Apollo — да, работает, ура!
Мы также можем для каждой сборки настроить список агентов, на которых она может выполняться. Зачем? Например, у нас на половине агентов линукс, а на половине винда. А сборку мы только под одну систему сделали. Или на винде вылезает какой-то плавающий баг, но исправлять его долго и дорого, а все клиенты на линуксе — ну и зачем тогда?
А еще бывает, что агентов делят между проектами, чтобы не было драки — этот проект использует Бурана и Аполло, а тот Чип и Дейла. Фишка ведь в том, что на одном агенте может выполняться только одно задание. Поэтому нет смысла покупать под агент крутую тачку, сразу кучу тестов там все равно не прогнать.
В итоге как это работает: сначала админ закупает компьютеры под «агенты» и устанавливает на них клиентское приложение TeamCity. Слишком крутыми они быть не должны, потому что много задач сразу делать не будут.
При этом TeamCity вы платите за количество лицензий на билд-агентов. Так что чем меньше их будет, тем лучше.
На отдельной машине админ устанавливает сервер TeamCity. И конфигурирует его — настраивает сборки, указывает, какие сборки на каких машинах можно гонять, итд. На сервере нужно место для хранения артефактов — результатов выполнения сборки.
У нас есть два проекта — Единый клиент и Фактор, которые взаимодействуют между собой. Тестировщик Единого клиента может не собирать Фактор локально. Он запускает сборку в TeamCity и скачивает готовый билд из артефактов!
Дальше уже разработчик выбирает, какую сборку он хочет запустить и нажимает «Run». Что в этот момент происходит:
1. Сервер TeamCity проверяет по списку, на каких агентах эту сборку можно запускать. Потом он проверяет, кто из этих агентов в данный момент свободен:
Нашел свободного? Отдал ему задачку!
Если все агенты заняты, задача попадает в очередь. Очередь работает по принципу FIFO — first in, first out. Кто первый встал — того и тапки.
Очередь можно корректировать вручную. Так, если я вижу, что очередь забита сборками, которые запустила система контроля версий, я подниму свою на самый верх. Если я вижу, что сборки запускали люди — значит, они тоже важные, придется подождать.
Это нормальная практика, если мощностей агентов не хватает на всей и создается очередь. Смотришь, кто ее запустил:
3. Сервер отрисовывает результат в графическом интерфейсе и сохраняет артефакты. Так я могу зайти в TeamCity и посмотреть в артефактах полные логи прошедших автотестов, или скачать сборку проекта, чтобы развернуть ее локально.
Настоятельно рекомендуется настроить заранее количество сборок, которые CI будет хранить. Потому что если в артефактах лежат билды по 200+ мб и их будет много, то очередной запуск сборки упадет с ошибкой «кончилось место на диске»:
4. Сервер делает рассылку по email — тут уж как настроите. Он может и позитивную рассылку делать «сборка собралась успешно», а может присылать почту только в случае неудачи «Ой-ей-ей, что-то пошло не так!».
Интеграция с VCS
Я говорила о разных вариантах настройки интеграции CI — VCS:
Но когда какой используется?
Лучше всего, конечно, чтобы система контроля версий оповещала сервер CI. И запускать весь цикл на каждое изменение: собрать, протестировать, задеплоить. Тогда любое изменение кода сразу попадет на тестовое окружение, которое будет максимально актуальным.
Плюс каждое изменение прогоняет автотесты. И если тесты упадут, сразу ясно, чей коммит их сломал. Ведь раньше работало и после Васиных правок вдруг сломалось — значит, это его коммит привел к падению. За редким исключением, когда падение плавающее.
Но в реальной жизни такая схема редко применима. Только подумайте — у вас ведь может быть много проектов, много разработчиков. Каждый что-то коммитит ну хотя бы раз в полчаса. И если на каждый коммит запускать 10 сборок по полчаса — очереди в TeamCity никогда не разгребутся!
У нас у одного из продуктов есть core-модуль, а есть 15+ Заказчиков. В каждом свои автотесты. Сборка заказчика — это core + особенности заказчика. То есть изменение в корневом проекте может повлиять на 15 разных сборок. Значит, их все надо запустить при коммите в core.
Когда у нас было 4 билд-агента, все-все-все сборки и тесты по этим заказчикам запускались в ночь на вторник. И к 10 утра в TeamCity еще была очередь на пару часов.
Другой вариант — закупить много агентов. Но это цена за саму машину + за лицензию в TeamCity, что уже сильно дороже, да еще и каждый месяц платить.
Поэтому обычно делают как:
1. Очень быстрые и важные сборки можно оставить на любой коммит — если это займет 1-2 минуты, пусть гоняется.
2. Остальные сборки проверяют, были ли изменения в VCS — например, раз в 15 минут. Если были, тогда запускаем.
3. Долгие тесты (например, тесты производительности) — раз в несколько дней ночью.
CI в тестировании
Если мы говорим о разработке своего приложения, то тестирование входит в стандартный цикл. Вы или ваши разработчики пишут автотесты, которые потом гоняет CI. Это могут быть unit, api, gui или нагрузочные тесты.
Но что, если вы тестируете черный ящик? Приложение есть, исходного кода нету. Это суровые реалии тестировщиков интеграции — поставщик отдает вам новый релиз приложения, который нужно проверить перед тем, как ставить в продакшен.
Вот, допустим, у вас есть API-тесты в Postman-е. Или GUI-тесты в Selenium. Можно ли настроить цикл CI для них?
CI не ставит жестких рамок типа «я работаю только в проектах с автотестами» или «я работаю только когда есть доступ к исходному коду». Он может смотреть в систему контроля версий, а может и не смотреть. Это необязательное условие!
Написали автотесты? Скажите серверу CI, как часто их запускать — и наслаждайтесь результатом =)
Итого
CI — непрерывная интеграция. Это когда ваше приложение постоянно проверяется: все ли с ним хорошо? Проходят ли тесты? Собирается ли сборка? Причем все проверки проводятся автоматически, без участия человека.
Особенно актуально для команд, где над кодом одного приложения трудятся несколько разработчиков. Как это бывает? По отдельности части программы работают, а вот вместе уже нет. CI позволяет очень быстро обнаружить такие проблемы. А чем быстрее найдешь — тем дешевле исправить.
Отсюда и название — постоянная проверка интеграции кусочков кода между собой.
Типичные задачи CI:
И все это — автоматически, без вмешательства человека! То есть один раз настроили, а дальше оно само.
Если в проекте настроен CI, у вас будут постоянно актуальные тестовые стенды. И если в коде что-то сломается, вы узнаете об этом сразу, сервер CI пришлет письмо. А еще можно зайти в графический интерфейс и посмотреть — все ли сборки успешные, а тесты зеленые? Оценить картину по проекту за минуту.
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале