Разработка программного обеспечения (ПО) – процесс только на первый взгляд кажущийся простым. Нередко, программы приходится переписывать практически с нуля, и весь процесс начинается заново.
Бойцы невидимого фронта
Разработка программного обеспечения (ПО) — процесс только на первый взгляд кажущийся простым. Прочитав предыдущую фразу, пытливый читатель сразу же скажет: «Да что ж тут сложного? Написал алгоритм — отдал заказчику и забыл».
Любая программа за всё время своего существования проходит сложный и нередко длительный процесс, начиная с проектирования и построения бизнес-логики, разработки дизайна, задания будущей структуры программы и юскейсов (usecase), и заканчивая написанием кода, его отладкой, выпуском и поддержкой уже готового ПО у конечного пользователя. Нередко, программы приходится переписывать практически с нуля, и весь процесс начинается заново.
Во всём этом процессе скрыта еще одна профессия, кроме всем известных программиста, тестировщика и инженера тех-поддержки — это профессия билд-инженера.
Все начинается с того, что весь код, который пишут программисты, все изображения и анимацию, которую создают дизайнеры, а также все другие файлы, из которых состоит будущий программный продукт, складывается в централизованное хранилище, называемое репозиторием или системой контроля версий файлов (Version Control System, VCS). Следующим шагом является сборка или «компиляция» кода в исполняемые файлы либо байт-код. Затем, код и полученные после компиляции файлы тестируют различными утилитами для автоматического тестирования, которые проверяют, правильно ли оформлен код в соответствии с существующими и принятыми на проекте стандартами, выполняет ли программа те функции, которые на неё возложены. Полученные результаты тестирования доставляются разработчикам, тестировщикам и менеджерам проекта для анализа. Cкомпилированный и протестированный код, запаковывается в установочные пакеты (installers), либо в специальные архивы, предназначенные для использования совместно с серверами приложений (Application Servers). Готовые пакеты/архивы доставляются тестировщикам для более тщательного тестирования уже готовых программ, либо устанавливаются на сервер с той же целью. А после, если они удовлетворяют поставленным требованиям, передаются заказчику.
Тем, кто уже успел подумать, что это всё, придется немного разочароваться: на этом процесс не заканчивается, потому что этот процесс — итерационный, или, проще говоря, циклический. Весь процесс сборки и тестирования, запаковки и отсылки повторяется регулярно, например, каждый день, чтобы иметь возможность полностью контролировать процесс разработки программного продукта и видеть, что же получается в любой момент этого процесса. Результат каждой такой итерации принято называть «билдом» (build).
Не так давно все описанные операции приходилось выполнять почти вручную, каждым из шагов мог заниматься отдельный человек, координация такой команды отнимала время и силы. Не говоря уже о человеческом факторе, когда ошибка на одном шаге останавливала работу всего «сборочного конвейера» («билд-процесса» от англ. «build process» или «билд-среды» от англ. «build environment»). Например, команда разработчиков может быть распределена по нескольким часовым поясам. И, если один из них, положил в репозиторий некорректный код, непроконтролировав это, то спустя несколько часов, другой разработчик на обратной стороне земного шара не сможет продолжить свою работу.
Для решения подобных проблем были придуманы различного рода инструменты, позволяющие тем или иным образом организовать сборочный конвейер и исключить факторы ошибок.
Вот тут-то на сцене и появляется билд-инженер (BE). Задачей билд-инженера является автоматизировать описанный выше процесс при помощи специализированных программ, сделать его максимально независящим от человека, чтобы все вышеописанные шаги выполнялись регулярно (каждый час) или по расписанию (каждую ночь), последовательно, и были предельно управляемыми, позволяя контролировать, в том числе и качество кода. Создание такого процесса называют Build Engineering или Continuous Engineering (CE), а результат — Continuous Integration (CI), непрерывная или постоянная интеграция.
Стоит отметить, что сама профессия билд-инженера как таковая появилась сравнительно недавно, на волне появления и развития утилит для автоматизации процесса сборки, тестирования и установки кода (для краткости будем называть его просто «сборкой кода»).
Ранее, на каждом проекте в ЕПАМ для целей создания CI выделялся отдельный человек, который совмещал написание кода и CE. Нередко таке люди не обладали необходимыми знаниями, и приходилось изучать технологии CI с нуля.
Несколько лет тому назад, в компании была создана специальная команда, впоследствии переросшая в отдельное инфраструктурное подразделение, обязанностями которой является непосредственная помощь всем проектам компании в создании CI (или «билд-инжиниринг»).
Преимущества такого подхода очевидны: сотрудники подобной команды занимаются только сборкой кода, они всегда в этой «теме», знают и умеют использовать большинство из существующих утилит, предназначенных для CI, могут не только предложить наиболее удачный для данного конкретного проекта подход в сборке кода, но и реализовать его на практике в кратчайшие сроки.
Adrenalin rush
Работа билд-инженера, это постоянный драйв. В самом начале, когда кода еще недостаточно для выполнения всех шагов CI, билд-процесс может состоять только из нескольких таких этапов. Впоследствии, по мере написания продукта, приходится добавлять оставшиеся.
Кроме того, не так уж редки случаи, когда процесс останавливается из-за какой-то ошибки, и билд-инженеру приходится искать её и исправлять. В этом очень помогает умение пользоваться поисковыми машинами для обнаружения информации в Глобальной Сети, поскольку, как известно, все новое, это хорошо забытое старое, и любая ошибка могла уже быть найдена кем-то другим, предложен путь её исправления.
Не менее важной является способность быстро обучаться и изучать новый инструментарий. На каждом проекте может использоваться свой набор утилит для тестирования, в том числе и принципиально новые, например, разработанные заказчиком или самим проектом, либо недавно появившиеся.
А как следствие того, что билд-инженер имеет отношение ко всем сторонам разработки программного продукта, не самым лишним качеством характера является и общительность, а также знание иностранных языков при работе в многонациональном проекте и/или с иностранным заказчиком.
Нередко, билд-инженеру приходится выступать и программистом, разрабатывая мелкие вспомогательные для него утилиты и скрипты, пополняя свой инструментарий. Конечно же, приходится также владеть хотя бы азами того языка программирования, код которого он собирает.
Кстати, вопросами грамотного хранения исходного кода программ в репозиториях также занимаются билд-инженеры: от того, как будет храниться код, может быть ускорен либо замедлен процесс разработки. Они же (билд-инженеры) и поддерживают сервера, на которых размещаются репозитории.
Зачастую билд-инженер поддерживает не один проект, а несколько. Несложно представить, какое количество адреналина появляется в крови билд-инженера, когда приходится заниматься несколькими срочными задачами одновмеренно.
Часовой на посту
Рабочий день билд-инженера начинается, как и у инженера тех-поддержки, с прочтения почты. Это и неудивительно, если учесть, что билд-инжиниринг тоже своего рода тех-поддержка. Как правило, за ночь приходят нотификации о прошедших билдах, что собралось, что не собралось, приходят запросы от проектных менеджеров на добавление или изменение тех или иных шагов билд-процесса. И, расставив приоритеты в полученных задачах, билд-инженер приступает к работе. В течение дня, на почту также приходят подобные письма.
Как правило, билд-процессы достаточно сложны, и билд-инженеру приходится также следить за ними. Если же грядущий билд очень важен для проекта, то даже запускать его вручную, несмотря на то, что чаще всего билды происходят по расписанию и запускаются каким-либо планировщиком задач.
При выполнении своей работы, билд-инженеру приходится отвечать на письма, переписываться с участниками проекта, который он поддерживает, участвовать в проектных митингах, обсуждать и предлагать различные идеи по сборке кода. Билд-инженер несет непосредственную ответственность за то, что код будет собран правильно, протестирован и доставлен по назначению. Работа по поддержке билд-сред очень важна: чтобы недопустить простой всей команды разработчиков, начиная от программистов и до тестировщиков, билд-среда должна работать как часы.
А после тяжелого трудового будня, билд-инженеры делятся своим опытом за кружкой чая.
В инженеры я б пошел, пусть меня научат!
Стать билд-инженером достаточно просто: достаточно иметь хотя бы часть тех умений, которые присущи билд-инженерам, ну или очень большое желание им стать вкупе с умением учиться на своем опыте и опыте других, а также умением решать проблемы самостоятельно.
Нелишним будет знание каких-либо технологий из XML, Java, dotNET, Ant, NAnt, Make, CruiseControl, Code Compilation, Unit Testing, Code Coverage, Subversion, Linux/Unix, любых сопутствующих технологий, а также английского языка.
Если что-то из вышеперечисленного вам присуще, то следующим шагом должно стать заполнение анкеты на сайте компании http://www.epam.by/ в разделе карьеры с указанием того, что вы хотите статьи билд-инженером и отсылка её на наш специальный почтовый адрес. В том случае, если ваша анкета будет интересна, впоследствии с вами свяжутся и проведут собеседование. А дальше — только вверх, через тернии к звездам!
Новым участникам команды, у которых желания больше чем знаний, присваивается звание Junior Software Maintenanse Engineer, что соответствует инженеру тех-поддержки на испытательном сроке. По его окончании, успешно прошедшие обучение в команде получают звание Software Maintenanse Engineer и становятся настоящими инженерами технической поддержки, занимающимися сборкой кода и поддержкой билд-процесса. Впоследствии, если билд-инженер показывает достаточно умений и знаний, чтобы справляться с поставленными задачами абсолютно самостоятельно, он может дорасти до старшего инженера тех-поддержки или Senior Software Maintenance Engineer. Ну а те, кто сможет заниматься не только своими делами, но и помогать другим это делать, а также закрывать собой сразу несколько направлений присваивается почетное звание ведущего специалиста, т.н. Lead Software Maintenance Engineer.
Если участник, пришедший в команду, обладает достаточно большим багажом знаний и умений, он может сразу получить более высокую «ступеньку» на карьерной лестнице, минуя первые несколько.
Ведущие специалисты, в течение длительного времени зарекомендовавшие себя как высококвалифицированные сотрудники, способные развивать компанию и вести её к новым вершинам , впоследствии могут стать менеджерами высшего звена.
Почти «криминальное чтиво»
Поскольку область билд-инжиниринга достаточно молода, найти сколь угодно внятную документацию по этой теме достаточно непросто. Тем не менее, если вам стало интересно, хороший набор информации по билд-инжинирингу и Continuous Integration доступен в книге «Continuous Integration: Improving Software Quality and Reducing Risk» издательства Addison-Wesley, авторы: Paul Duvall, Steve Matyas, Andrew Glover. Также, информация на русском языке доступна по следующему адресу в Интернете http://lib.custis.ru/index.php/Continuous_Integration.
Автор:
Дмитрий Змитраченок (27 лет), EPAM Systems
- Окончил Белорусский государственный университет информатики и радиоэлектроники, специальность- инженер- cистемотехник.
- Начинал карьеру как разработчик на C/C++ в Объединенном институте проблем информатики НАН Беларуси в области обработки речевых сигналов, распознавания и синтеза речи.
- С 2005 года работает в компании EPAM Systems в команде по разработке и поддержке систем непрерывной интеграции (Continuous Engineering Support).
- Также занимается проведением семинаров по системе контроляверсий Subversion и поддержкой Subversion-сервисов.
- Ведущий программист (Technical Support Team Leader).
01.24.08, "Мой Компьютер", (c) EPAM Systems
http://www.epam.by/pdf/Pages%20from%20Mk_044_16-17.pdf