В очередном докладе компании GitHub State of the Octoverse говорится, что число учетных записей пользователей на сайте GitHub (за исключением фальшивых спамерских записей) дошло до 40 миллионов. Ясно, впрочем, что не все эти пользователи являются разработчиками программ. В GitHub подсчитывают общее число учетных записей, независимо от их активности и участия в разработке проектов, исходные коды которых размещены на сайте. Учетные записи на GitHub создают не только разработчики, но и сотрудники маркетинговых отделов и руководители по продуктам, отмечает обозреватель InfoWorld, а многие разработчики заводят по несколько учетных записей. У GitHub должны быть данные об активности пользователей, но компания не публикует подобных сводных отчетов.

По оценкам IDC, в мире насчитывается порядка 5 млн разработчиков программ, работающих на условиях полной занятости, 7 млн частично занятых и еще 7 млн разработчиков, работающих бесплатно — всего 24,2 млн.

В докладе GitHub приведены и другие интересные данные: например, 80% правок исходного кода в проекты поступает из-за пределов США, а 36% частных репозиториев кода приходится на страны Азии.

Некоммерческое партнерство «Руссофт» существует уже 20 лет. За это время отечественная индустрия разработки ПО прошла путь от отдельных структур, специализирующихся на услугах офшорной разработки, до ведущих игроков мирового рынка заказного ПО, находящегося сегодня на подъеме благодаря цифровой трансформации. «Наши компании добились признания как на развитых, так и на развивающихся рынках. В стране происходит смещение в сторону отечественного ПО: совокупный оборот российских софтверных компаний достиг 997 млрд руб.», — отметил Валентин Макаров, президент НП «Руссофт», открывая заседание юбилейного пресс-клуба, в котором приняли участие руководители компаний «Аплана», «Базальт СПО», «Ланит-Терком», «Форсайт», Artezio, Astra Linux, Auriga, ВСС, Diasoft, EPAM, Reksoft, SPIRIT и First Line Software, входящих в партнерство, объединяющее сегодня сотни компаний, разрабатывающих как собственные продукты, так и заказные программные системы.

Многие участники пресс-клуба прошли вместе с «Руссофтом» путь от небольших команд до крупнейших международных компаний численностью порядка 40 тыс. сотрудников. Юрий Овчаренко, заместитель генерального директора EPAM, в своем выступлении отметил, что компания работает на четырех континентах в 25 странах: мир узнал про российских разработчиков ПО. Компания движется к консалтингу, надеясь через ассоциации разработчиков навести мосты между государством, российским бизнесом и ИТ при реализации проектов цифровой трансформации. Вместе с тем, указал Овчаренко, имеются проблемы, которые мешают дальнейшему расширению российской софтверной индустрии. В числе этих проблем — кадровый голод, по причине которого не хватает специалистов для выполнения всех заказов. К этой теме не раз возвращались в ходе обсуждений на пресс-клубе; в частности, речь шла о том, что дефицит специалистов приводит к высоким зарплатам, из-за этого снижается маржинальность бизнеса и теряется конкурентоспособность.

Игорь Никифоров, генеральный директор BCC, посвятил свое выступление вопросам подготовки кадров для цифровой экономики. Он полагает, что сегодня остро необходимы универсальные специалисты, хорошо разбирающиеся и в конкретной прикладной области (химии, биологии, медицине), и в программировании. Здесь, по мнению Вячеслава Ванюлина, генерального директора компании Auriga, могут помочь исследовательские лаборатории, которые разрабатывают и тестируют новые решения в интересах компаний-заказчиков, не обладающих экспертизой в определенной прикладной сфере или ресурсами для развертывания и эксплуатации соответствующих программно-аппаратных платформ.

Владимир Литошенко, старший вице-президент First Line Software, сравнил 20-летнюю историю развития отечественной индустрии разработки ПО с «американскими горками» – то взлеты, то чреватые падением ограничения. К счастью, сегодня уже не надо доказывать всему миру, что российские разработки будут выполнены в срок, качественно и надежно. При этом, как констатировал Виктор Вайнштейн из группы «Аплана», в области высокоинтеллектуальных услуг, например в обеспечении качества ПО, российские поставщики сегодня лидируют.

Роман Малицин из компании Astra Linux обратил внимание, что дома по-прежнему продвигать решения сложнее, чем за рубежом: апробированные в отечественных ведомствах решения конкурентоспособны на Западе, но для успеха на рынках требуется кооперация всех российских игроков, чтобы предлагать заказчикам не отдельный продукт, а функционально полный стек технологий и консалтинговых услуг. Александр Егоров, генеральный директор Reksoft, отметил, что для любого проекта цифровой трансформации, такого, например, как цифровой экспедитор для международных перевозок, критичны стыковка различных данных, интеграция технологических платформ, и поэтому остро необходимо взаимодействие поставщиков. Вадим Сабашный, директор по производству «Ланит-Терком», привел в качестве примера проект, выполненный для заказчика из Индии, но прошедший прежде через цепочку компаний-посредников из США и Израиля. Владимир Комов, генеральный директор «Форсайта», посвятил свое выступление развитию отечественного ПО, указав, что часто, вопреки декларациям с высоких трибун и наличию российских аналогов, решение по проектам для госзаказчиков все еще принимается в пользу зарубежных поставщиков, причем отечественные разработчики под разными предлогами даже не допускаются до конкурсов.

В ходе заседания пресс-клуба обсуждалась новая для российской софтверной индустрии тенденция, требующая пересмотра перспектив развития отечественного рынка разработки ПО: приобретение зарубежными корпорациями отечественных компаний (в пример приводились Parallels, Transas, Luxoft) при отсутствии интереса к перспективным компаниям со стороны российских госкорпораций и крупного бизнеса. Участники заседания сошлись во мнении, что ничего страшного в этой тенденции нет — но только при условии, если такие приобретения не будут заканчиваться перераспределением ресурсов в пользу, например, азиатских компаний, в скрытой форме решающих свои кадровые проблемы. Кроме того, экспертиза должна не уходить за рубеж, а продолжать развиваться «дома». Государство пока в данном процессе не участвует – госкорпорации, переманивая кадры, в том числе и из регионов, создают собственные ИТ-подразделения, чтобы решать корпоративные задачи, забывая, что такая практика в отечественной ИТ-истории уже была и себя не оправдала: качество решений оказывается ниже, а стоимость выше, чем у тех, что предлагаются компаниями, имеющими возможность работать со многими заказчиками и в различных отраслях.

По расчетам «Руссофта», совокупный оборот предприятий отечественной индустрии ПО в 2019 году может продолжить рост на 17,6% и составить 1,21 трлн руб, однако кадровый голод и ряд других факторов способны помешать осуществиться этим прогнозам.

Компания SAP построила свой дистрибутив Java на основе OpenJDK — известной версии платформы Java с открытым исходным кодом. Дистрибутив получил название SapMachine. Клиенты и партнеры SAP могут свободно запускать на нем свои приложения, написанные на языке Java.

В компании подчеркивают, что SapMachine является не конкурирующей, а дружественной по отношению к основному дистрибутиву версией. Представители SAP входят в исполнительный комитет JCP (Java Community Process), выпускающий спецификации платформы Java, и участвуют в разработке OpenJDK.

Выпуски SapMachine будут производиться синхронно с выпусками очередных версий OpenJDK. Текущая версия SapMachine носит номер 11 и имеет статус версии с долгосрочной поддержкой. 19 марта планируется выпустить версию SapMachine 12, соответствующую версии Java Development Kit (JDK) 12.

Работа SapMachine поддерживается на операционных системах Windows, Linux и MacOS. Большинство версий выпускается также в виде контейнеров Docker. Дистрибутив SapMachine прошел проверку на совместимость с помощью Java Compatibility Kit. Начиная с версии 12, в компании планируют поддерживать одновременно несколько версий SapMachine.

На конференции WWDC в прошлом году представители компании Apple утверждали, что планов по объединению систем iOS и macOS у компании нет, но разработчики со временем получат возможность писать приложения, работающие на обеих системах, используя платформу под названием Marzipan. С тех пор новостей о ходе разработки этой платформы не поступало, но журналист агентства Bloomberg утверждает, что она продолжается и что платформа Marzipan станет одной из главных тем предстоящей конференции WWDC. Сначала Apple представит набор средств разработчика для переноса приложений с iPad на Mac, затем, в 2020 году, выпустит аналогичный набор для переноса приложений с iPhone. К 2021 году будет реализована возможность создания одного бинарного файла программы, работающей на Mac, iPad и iPhone. Разумеется, разработчикам при этом придется учитывать различие интерфейсов iOS и macOS.

На конференции WWDC может быть также представлена новая модель Mac Pro, некоторые офисные приложения для iPad и новое темное оформление интерфейсов всех устройств для работы при малом освещении. Конференция, по некоторым сообщениям, пройдет с 3 по 7 июня в Сан-Хосе (Калифорния).

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

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

«Надо наводить порядок – все будут этому рады. Хотя и не сразу покажут это», — отметил Скрынник.

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

Следующая проблема – неоднородность технических практик. Необходимо провести их ревизию, выявить лидеров и отстающих, а также очаги современных подходов. Учить и разъяснять, искать примеры внутри. Так устраняется неоднородность, и подразделение начинает двигаться вперед.

Отдельный вопрос, актуальный для многих, — где брать наставников? Agile-команды сами собой не заработают, а коучей в компаниях нет. Самоорганизация возможна и должна поощряться, но на нее не стоит рассчитывать на ранних стадиях формирования команд. Рынок внешнего труда тоже не поможет – он перегрет и пуст, надо искать перспективных кандидатов внутри, создавать свои школы. Большая иллюзия, что на каждую команду удастся выделить по скрам-мастеру, — это дорого и нереально. Им придется совмещать работу в нескольких командах.

Еще один бич большинства компаний – отсутствие измерений. Как правило, в разработке ПО объективно никто ничего не знает: есть одни ощущения, планы и сорванные сроки. В лучшем случае для отчетности используются стандартные диаграммы из Jira. Здесь можно посоветовать использовать визуализацию: рисовать поток создания ценности, ставить отметки по времени, и не бояться сравнивать команды между собой.

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

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

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

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

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

Для чего нужна непрерывная интеграция?

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

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

Крупные команды, испытывающие постоянную потребность в разработке и развертывании, быстро придумали новый подход, при котором изменения вносятся часто, а проверка сборки и функциональности выполняется с помощью средств автоматизации. Такой подход получил название непрерывная интеграция (continuous integration, CI).

Определение непрерывной интеграции

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

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

Как непрерывная интеграция работает на практике

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

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

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

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

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

Процесс сборки автоматизируется путем упаковки всего программного обеспечения, базы данных и других компонентов. Например, если вы разрабатываете приложение Java, средства CI упакуют все статические файлы веб-сервера (HTML, CSS и JavaScript) вместе с приложением Java и скриптами базы данных.

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

Рабочие процессы здесь называются конвейером CI.

Разработка и тестирование с использованием непрерывной интеграции

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

После успешного прохождения основных тестов выполняется фиксация кода. Платформа CI (например, Jenkins или Travis) запускает сборку, в которой все элементы кода помещаются в один или несколько строительных блоков. Затем процедура CI проводит анализ статического кода и сообщает разработчикам об обнаруженных в сборке ошибках.

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

После того, как программное обеспечение упаковано, инструменты CI могут помочь вам перенести сборку программного обеспечения в среду его поставки, активизировать необходимые сервисы (например, перезапустить серверы приложений) и выполнить любые автоматизированные тесты. Эти шаги обычно называют непрерывной поставкой (continuous delivery, CD), а функции тестирования, встроенные в конвейер непрерывных интеграции и поставки (CI/CD), становятся компонентами непрерывного тестирования.

Команды, использующие в своей деятельности CI/CD, способны быстрее предлагать пользователям новые функции и расширения. Средства автоматизации и технологические процессы позволяют сократить объемы написания кода и уменьшить число функциональных дефектов. Технологические процессы такого рода укрепляют взаимодействие в команде и помогают создавать интеллектуальные, еще более инновационные решения. И все это начинается с непрерывной интеграции.

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

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

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

В сопроводительной документации к новой версии указано, что с 13 сентября система перестанет поддерживать браузер Internet Explorer 11. GitHub Enterprise 2.14 предлагается в вариантах для локального и облачного развертывания.

Согласно данным «Русссофт», совокупный оборот всех российских компаний-разработчиков ПО в 2017 году составил 14,3 млрд. долл. Это на 19% больше, чем в 2016 году. В рублях показатель вырос на 4% и достиг 834 млрд. рубл.

Продажи российских компаний за рубежом составили в минувшем году 8,8 млрд. долл., что на 16% больше, чем годом ранее. При подсчете учитывались в том числе продажи условно российских компаний — тех, что имеют основной центр разработки в России, основаны в России и управляются бывшими или настоящими российскими гражданами. Экспорт «компьютерных услуг» составил 3,417 млрд долл., продажи показали рост в 28,3%. Общий приток валюты, составляет 5,5 млрд долл. Экспорт ИТ достигает 8-9 млрд долл.

Совокупные продажи на внутреннем рынке выросли 9%, до 321 млрд. руб. Российские софтверные компании нарастили продажи чуть больше, чем увеличился сам рынок: разработчики увеличили продажи на внутреннем рынке, опережая рост самого рынка на 5%. В 2017 году это показаетль составлял 30%. Таким образом, что процесс импортозамещения несколько замедлился.

Зарубежные продажи аутсорсинговых компаний росли быстрее, чем у разработчиков тиражируемых решений. В 2017 году возросла активность небольших компаний (с оборотом 1 — 5 млн долл.) за пределами страны. Несмотря на восстановление внутреннего рынка, оборот компаний, у которых 50% выручки приходится на зарубежные продажи, по-прежнему выше, чем у тех, что половину выручки получают на российском рынке. Однако эта разница стала меньше.

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

На конференции Windows Developer Day корпорация Microsoft объявила о том, что в следующем обновлении Windows 10 будет представлена платформа для разработчиков по работе с искусственным интеллектом Windows ML. Она позволит «наделять» пользовательские приложения на Windows 10 «умными» функциями значительно проще и быстрее.

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

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

Платформа Windows ML будет поддерживаться устройствами на Windows: ноутбуками, стационарными ПК, периферийными устройствами Интернета вещей, серверами, дата-центрами и даже гарнитурой смешанной реальности Microsoft HoloLens.

В Microsoft утверждают, что конечной целью корпорации является широкое распространение и демократизация технологий искусственного интеллекта.

Организация Eclipse Foundation подвела итоги голосования за новое название корпоративной платформы Java Enterprise Edition (Java EE). На голосование было предложено два варианта: Jakarta EE и Enterprise Profile. Было подано 6959 голосов, и с результатом 64,4% победило название Jakarta EE.

Право на использование марки Jakarta EE будет предоставляться технологическим платформам после прохождения тестирования на совместимость. Однако программа тестирования еще не разработана. Ее созданием займется рабочая группа организации Eclipse под названием EE.Next.

Название Jakarta используется в одном из проектов Apache Software Foundation, тоже связанном с платформой Java, но, как утверждают в Eclipse, в Apache не возражают против использования этого названия.