NAB обнародовала первые детали девятимесячной работы, которую она называет NAB Engineering Foundation (NEF), включающей стандартизированные методы и “повторяемые быстрые старты”, чтобы помочь разработчикам быстрее запустить код в производство.
НЭФ до сих пор оставался в значительной степени вне поля зрения общественности, несмотря на то, что в настоящее время считается, что это значительные усилия, используемые более чем 100 отрядами инженеров по всему банку.
Выдающийся инженер Эндрю Брайдон заявил на саммите HashiCorp financial services executive summit в начале этого месяца, что NEF родился в начале 2020 года для решения “сложностей” в том, как разработчики пишут код, особенно для облака.
NEF возникла отчасти потому, что незначительные различия в том, как разные команды разработчиков подходили к проблемам и кодировали компоненты, привели к большим “сложностям” в банке.
“Команды по отдельности создавали одни и те же компоненты для облака и приложения на облаке немного по-разному”, — сказал Брайдон.
“Команды, конечно, все время заимствуют друг у друга, но они берут вещи, они развивают их и обновляют, и мы обнаружили, что это отсутствие стандартизации действительно иногда тормозит некоторую скорость доставки.
“У него также есть некоторые другие ударные воздействия. Перемещение инженеров между командами может стать сложнее, потому что в этом есть элемент переподготовки.”
Внутри НЕФА
NEF представлен разработчикам и отрядам как “продукт … для загрузки и развертывания”.
Технически он состоит из “множества различных компонентов … это мы предварительно интегрируем, чтобы обеспечить шаблон разработки для всех команд разработчиков”, — сказал Брайдон.
В рамках NEF Terraform Enterprise (TFE) HashiCorp используется “для поддержки стандартизированной тяжелой работы по развертыванию инфраструктуры”, в то время как Jenkins Templating Engine (JTE) обеспечивает многоразовый “стандартный конвейер CI/CD”.
“Принимая во внимание, что мы являемся строго регулируемой организацией, TFE позволяет нам встроить элемент наших требований соответствия через Sentinel [структуру политики HashiCorp как кода]»,-сказал Брайдон.
“Модули Terraform на самом деле также являются открытым исходным кодом в нашей организации. Итак, у нас есть организация GitHub, которая содержит все многоразовые модули Terraform, которые команды могут развертывать в своих рабочих пространствах.”
Разработчики банка также посещают “стандартный набор буткемпов”, охватывающий такие темы, как “разработка инфраструктуры как кода с помощью Terraform, разработка на Java и Javascript, а также контейнеры на шаблонной платформе контейнерных сервисов”.
“Мы провели серию буткемпов внутри компании, чтобы подготовить наших инженеров к работе в этом стандартном подходе”, — сказал Брайдон.
“Вы должны обучать людей тому, как делать вещи, чтобы они знали, что делать, и мы рассматриваем это как один из наших ключевых столпов, чтобы сделать это в нашей организации.
— Любой новый инженер, поступающий в банк, проходит эту подготовку. [Как только они] регистрируются в GitHub, мы отправляем им электронное письмо, чтобы помочь им подняться в наши буткемпы.”
Брайдон сказал, что стандартизация должна позволить разработчикам гораздо быстрее внедрять более ориентированные на клиента инновации и функции.
“Мы были очень систематичны в том, как мы работали внутри команд и понимали их требования, и стандартизация таким образом является реальным преимуществом производительности”, — сказал он.“Это означает, что мы фокусируемся на скорости разработки программного обеспечения, и если вы знакомы с некоторыми цитатами вокруг Spotify, то если вы фокусируетесь на скорости, то качество-это быстрый последователь.
“Так что это одна из вещей в глубине нашего сознания, когда мы делаем это.”
Банк создает библиотеку того, что он называет “повторяемыми быстрыми запусками”, которые призваны помочь разработчикам гораздо быстрее внедрять новые устойчивые функции в производство.
ITnews понимает, что еще больше таких повторяемых быстрых стартов будет построено в течение 21 финансового года.
Принятие внутреннего источника
Другая часть NEF-это принятие NAB innersource, набора методов разработки программного обеспечения, используемых для создания культуры с открытым исходным кодом внутри организации.
Брайдон сказал, что innersource гарантирует, что центральный потенциал, которым является NEF, со временем не станет узким местом для инноваций.
“Мы используем подход с открытым исходным кодом или внутренним источником внутри организации, и это означает, что любая команда может предоставлять обновления и вносить изменения в эту возможность”, — сказал он.
В своем посте в LinkedIn НАБ сообщил, что внутренний брендинг для программы innersource был запущен разработчиками банка только в прошлом месяце.
“В начале этого года мы запустили нашу программу NAB innersource, чтобы сломать силосы на предприятии и позволить нашим разработчикам работать над кодом в открытом режиме”, — говорится в сообщении.
“Мы видим реальные ощутимые выгоды от этого с уменьшением затрат на доставку за счет повторного использования компонентов, более быстрого времени создания ценности для клиентов, наставничества, инноваций и более высокой вовлеченности.”
Модель innersource означает, что разработчики NAB больше не участвуют в специальном совместном использовании кода.
Вместо этого они могут получить доступ к коду, созданному другими командами, но также и внедрять инновации поверх него, чем другие команды могут немедленно воспользоваться.
“Мы видим, что модель innersource-это ключ к тому, чтобы иметь возможность масштабировать что-либо с точки зрения современной разработки программного обеспечения в такой организации, как наша”, — сказал Брайдон.
— Я приведу вам пример того, насколько это может быть эффективно.
“Нам нужно было перейти на новую версию модулей [Terraform] для Azure. В NAB вы можете развертывать среды Azure только через TFE. Это то, что мы сделали в качестве стандарта.
“Нам нужно было обновить сразу 40 модулей, и с помощью этой модели «краудсорсинга», которая у нас есть, мы могли бы сделать это в течение нескольких дней.”
