Core release что это

Introduction

Intel works with periodic releases of the iwlwifi driver that are tested with a specific combination of components. They are called LinuxCore releases and are numbered sequentially, e.g. LinuxCore11 is the latest stable release as of May 2015. These releases can be seen as snapshots of the development trees (including upstream) that are tested thoroughly together with a specific version of the firmware and userspace components (i.e. hostap).

Components

The components used in each release are specific stabilization versions of the following:

Who are you?

If you use a well known distribution

If you use a well maintained distribution, your device should be supported out of the box. If your device doesn't work at all (you can't even see it in the interface list), then it might mean that your kernel is too old or that you don't have the proper firmware. You can contact your distribution to have them fix this. In the meantime, you can use the backport tree to make your device work. Make sure to install the proper firmware as well. If your device works minimally (you can see it in the interface list), but you experience issues, please check the support section. You can also use the backport tree to check if the issue you are suffering from has been fixed in different releases. The backport tree is also an excellent tool to bisect regressions. Note that when you install the backport drivers, you disallow the usage of any WLAN device that is not supported by iwlmvm. To check if your device is supported by iwlmvm, please check here in the module column.

If you are building your own system

If you are building your own system and you know that the only WLAN device you'll have is from Intel, the backport tree is what you need. You'll be able to get a driver / firmware combo that has been validated together. As a rule of thumb, you should take the latest Core version available.

A note about upstream policy

The fact that Intel published a backport tree for its WLAN drivers doesn't impact its commitment to upstream all the code to the mainline kernel. It simply allows users who can't choose their kernel to work with a more recent driver. The backport tree allows us to provide a combo of the driver / firmware that has been fully validated. For a simple reason of capacity, we cannot test as thoroughly all the kernel versions / firmwares / devices matrix. There is code in the backport tree that is not in the mainline kernel, but this is transient. Eventually, all the code in the backport tree will reach mainline unless it has dependencies (platform drivers etc…).

Core release

A Core release includes all the components described above . Here is the way to match all these components together. backport, iwlwifi, mac80211 and cfg80211 come from the backport-iwlwifi git repository. You'll find the relevant Core branches there (release/LinuxCoreX). For all the Core releases, the master branch hostap should be taken. The firmware can be found in iwlwifi's linux-firmware clone. Please don't open bugs on versions that are advertised as End of life. Here is the table to help you finding the right version of the different components:

Core release	status	backport-iwlwifi	Firmware API number
Core14	Last version for 7260, 7265 and 3160	LinuxCore14	-17.ucode 7260 3160 7265
Core26	Last version for 3168 and 7265D	LinuxCore26	-29.ucode 7265D3168
Core33	Last version for 8260 and 8265	core33	-36.ucode 82608265
Core43	Last version for 9260 and 9000	core43	-46.ucode 92609000AX 200
Core45	maintained	core45	-48.ucode AX 200
Core47	maintained	core47	-48.ucode AX 200

Devices not maintained in mainline

From time to time, we remove support for existing devices from the mainline code base of the firmware. This means that those devices won't benefit from new features, but bug fixes will be back-ported to the Core release branch on which they are supported. For those devices, it is recommended to take the latest Core available for the driver and the latest firmware. For example for 7260, the Core14 firmware should be used together with the latest Core available for the driver. The driver for all those devices is maintained as part of the kernel, but they won't get newer firmware features. Those devices and the latest Core firmware that supports them are:

Making a SilverStripe core release#

This guide is intended to be followed by core contributors, allowing them to take the latest development branch of each of the core modules, and building a release. The artifacts for this process are typically:

• A downloadable tar / zip on silverstripe.org
• A published announcement
• A new composer installable stable tag for silverstripe/installer

While this document is not normally applicable to normal silverstripe contributors, it is still useful to have it available in a public location so that these users are aware of these processes.

First time setup#

As a core contributor it is necessary to have installed the following set of tools:

First time setup: Standard releases#

• PHP 5.5+
• Python 2.7 / 3.5

cow release tool. This should typically be installed in a global location via the below command. Please see the installation docs on the cow repo for more setup details.

• composer global require silverstripe/cow dev-master

transifex client. You will also need to ensure that your transifex account has been granted the necessary write permissions on the cms, framework, installer, simple theme, siteconfig and reports modules:

• pip install transifex-client

• pip install awscli

You will also need to be assigned the following permissions. Contact one of the SS staff from the core committers, who will assist with setting up your credentials.

• Write permissions on the silverstripe and silverstripe-labs organisations.
• Moderator permissions on the community forum.
• Admin permissions on transifex.
• AWS write permissions on the silverstripe-ssorg-releases s3 bucket.
• Permission on silverstripe release announcement.
• Moderator permissions in the #silverstripe IRC channel
• Administrator account on docs.silverstripe.org and userhelp.silverstripe.org.

First time setup: Security releases#

For doing security releases the following additional setup tasks are necessary:

• Write permissions on the silverstripe-security organisation.
• Permission granted on the open source security JIRA
• Permissions to write to the security releases page and the silverstripe.org cms.
• Permission on security pre-announcement mailing list.

Security release process#

When doing a security release, typically one or more (or sometimes all) of the below steps will need to be performed manually. As such, this guide should not be followed exactly the same for these.

Standard practice is to produce a pre-release for any patched modules on the security forks for cms and framework (see silverstripe-security).

Producing a security fix follows this general process:

• When a security issue is disclosed on security@silverstripe.com it should be given a CVE (common vulnerability exposure) code. E.g. ss-2015-020. Make sure you thank anyone who disclosed this issue, and confirm with them as soon as possible whether this issue is a verified security issue.
• Log this CVE, along with description, release version, and name of reporter in JIRA at open source security jira.
• Create a similar record of this issue on the security releases page in draft mode.
• Post a pre-announcement to the security pre-announcement list. It's normally ideal to include a VCSS (common vulnerability scoring system) along with this pre-announcement. If the release date of the final stable is not known, then it's ok to give an estimated release schedule.
• Push the current upstream target branches (e.g. 3.2) to the corresponding security fork to a new branch named for the target release (e.g. 3.2.4). Security fixes should be applied to this branch only. Once a fix (or fixes) have been applied to this branch, then a tag can be applied, and a private release can then be developed in order to test this release.
• Once release testing is completed and the release is ready for stabilisation, then these fixes can then be pushed to the upstream module fork, and the release completed as per normal. Make sure to publish any draft security pages at the same time as the release is published (same day).
• After the final release has been published, close related JIRA issues at open source security jira

Standard release process#

The release process, at a high level, involves creating a release, publishing it, and reviewing the need for either another pre-release or a final stable tag within a short period (normally within 3-5 business days).

During the pre-release cycle a temporary branch is created, and should only receive absolutely critical fixes during the cycle. Any changes to this branch should result in the requirement for a new release, thus a higher level of scrutiny is typically placed on any pull request to these branches.

When creating a new pre-release or stable, the following process is broken down into two main sets of commands:

Stage 1: Release preparation:#

If you are managing a release, it's best to first make sure that SilverStripe marketing are aware of any impending release. This is so that they can ensure that a relevant blog post will appear on www.silverstripe.org/blog, and cross-posted to other relevant channels such as Twitter and Facebook. Sending an email to marketing@silverstripe.com with an overview of the release and a rough release timeline.

Check all tickets (framework, cms, installer) assigned to that milestone are either closed or reassigned to another milestone.

Merge up from other older supported release branches (e.g. merge 3.1 -> 3.2 , 3.2 -> 3.3 , 3.3 -> 3 , 3 -> master ).

This is the part of the release that prepares and tests everything locally, but doe not make any upstream changes (so it's safe to run without worrying about any mistakes migrating their way into the public sphere).

Invoked by running cow release in the format as below:

• <version> The version that is to be released. E.g. 3.2.4 or 3.2.4-rc1
• <prior-version> The version from which to compare to generate a changelog. E.g. 3.2.3 (if releasing 3.2.4), or 3.2.5 (if releasing 3.3.0 and that's the newest 3.2.x version). You can normally leave this out for patch releases, and the code will normally be able to guess the right version, but you may as well declare it every time.
• —branch-auto Will automatically create a new temporary release branch (e.g. 3.2.4) if one does not exist.

This can take between 5-15 minutes, and will invoke the following steps, each of which can also be run in isolation (in case the process stalls and needs to be manually advanced):

• realease:create The release version will be created in the release-<version> folder directly underneath the folder this command was invoked in. Cow will look at the available versions and branch-aliases of silverstripe/installer to determine the best version to install from. E.g. installing 4.0.0 will know to install dev-master, and installing 3.3.0 will install from 3.x-dev. If installing pre-release versions for stabilisation, it will use the correct temporary release branch.
• release:branch If release:create installed from a non-rc branch, it will create the new temporary release branch (via —branch-auto ). You can also customise this branch with —branch=<branchname> , but it's best to use the standard.
• release:translate All upstream transifex strings will be pulled into the local master strings, and then the i18nTextCollector task will be invoked and will merge these strings together, before pushing all new master strings back up to transifex to make them available for translation. Changes to these files will also be automatically committed to git.
• release:test Will run all unit tests on this release. Make sure that you setup your _ss_environment.php correctly (as above) so that this will work.
• release:changelog Will compare the current branch head with —from parameter version in order to generate a changelog file. This wil be placed into the ./framework/docs/en/04_Changelogs/ folder. If an existing file named after this version is already in that location, then the changes will be automatically regenerated beneath the automatically added line: <!— Changes below this line will be automatically regenerated —> . It may be necessary to edit this file to add details of any upgrading notes or special considerations. If this is a security release, make sure that any links to the security registrar (http://www.silverstripe.org/download/security-releases) match the pages saved in draft.

Once the release task has completed, it may be ideal to manually test the site out by running it locally (e.g. http://localhost/release-3.3.4 ) to do some smoke-testing and make sure that there are no obvious issues missed.

Since cow will only run the unit test suite, you'll need to check the build status of Behat end-to-end tests manually on travis-ci.org for the various modules (e.g. framework) and cms).

It's also ideal to eyeball the git changes generated by the release tool, making sure that no translation strings were unintentionally lost, no malicious changes were introduced in the (community contributed) translations, and that the changelog was generated correctly.

In particular, double check that all necessary information is included in the release notes, including:

• Upgrading notes
• Security fixes included
• Major changes

Once this has been done, then the release is ready to be published live.

Stage 2: Release publication#

Once a release has been generated, has its translations updated, changelog generated, and tested, the next step is to publish the release. This involves tagging, building an archive, and uploading to www.silverstripe.org download page.

Invoked by running cow release:publish in the format as below:

subtasks which are invoked in sequence:

• release:tag Each module will have the appropriate tag applied (except the theme).
• release:push The temporary release branches and all tags are pushed up to origin on github.
• release:archive This will generate a new tar.gz and zip archive, each for cms and framework-only installations. These will be copied to the root folder of the release directory, although the actual build will be created in temporary directories (so any temp files generated during testing will not end up in the release). If the tags generated in the prior step are not yet available on packagist (which can take a few minutes at times) then this task will cycle through a retry-cycle, which will re-attempt the archive creation periodically until these tags are available.
• release:upload This will invoke the AWS CLI command to upload these archives to the s3 bucket silverstripe-ssorg-releases . If you have setup your AWS profile for silverstripe releases under a non-default name, you can specify this profile on the command line with the —aws-profile=<profile> command.

Once all of these commands have completed there are a couple of final tasks left that aren't strictly able to be automated:

• If this is a stable release, it will be necessary to perform a post-release merge on open source. This normally will require you to merge the temporary release branch into the source branch (e.g. merge 3.2.4 into 3.2), or sometimes create new branches if releasing a new minor version, and bumping up the branch-alias in composer.json. E.g. branching 3.3 from 3, and aliasing 3 as 3.4.x-dev. You can then delete the temporary release branches. This will need to be done before updating the release documentation in stage 3.
• Merging up the changes in this release to newer branches, following the SemVer pattern (e.g. 3.2.4 > 3.2 > 3.3 > 3 > master). The more often this is done the easier it is, but this can sometimes be left for when you have more free time. Branches not receiving regular stable versions anymore (e.g. 3.0 or 3.1) should usually be omitted.

Set the github milestones to completed, and create placeholders for the next minor versions. It may be necessary to re-assign any issues assigned to the prior milestones to these new ones. See the below links for each module milestone list:

Updating non-patch versions

If releasing a new major or minor version it may be necessary to update various SilverStripe portals. Normally a new minor version will require a new branch option to be made available on each site menu. These sites include:

• New branches (minor releases) require a code update. Changes are made to

• Updated similarly to docs.silverstripe.org: Code changes are made to

• Updates to markdown made via the build tasks.

: Update on github and deployed via SilverStripe Platform. Currently the only way to rebuild the api docs is via SSH in and running the apigen task.

It's also a good idea to check that Deprecation::notification_version('4.0.0'); in framework/_config.php points to the right major version. This should match the major version of the current release. E.g. all versions of 4.x should be set to 4.0.0 .

Updating markdown files

When updating markdown on sites such as userhelp.silverstripe.org or docs.silverstripe.org, the process is similar:

• Run RefreshMarkdownTask to pull down new markdown files.
• Then RebuildLuceneDocsIndex to update search indexes.

Running either of these tasks may time out when requested, but will continue to run in the background. Normally only the search index rebuild takes a long period of time.

Note that markdown is automatically updated daily, and this should only be done if an immediate refresh is necessary.

Stage 3: Let the world know#

Once a release has been published there are a few places where user documentation will need to be regularly updated.

• Make sure that the download page on silverstripe.org has the release available. If it's a stable, it will appear at the top of the page. If it's a pre-release, it will be available under the development builds section. If it's not available, you might need to check that the release was properly uploaded to aws s3, or that you aren't viewing a cached version of the download page. You can cache-bust this by adding ?release=<version> to the url. If things aren't working properly (and you have admin permissions) you can run the CoreReleaseUpdateTask to synchronise with packagist.
• Ensure that docs.silverstripe.org has the updated documentation by running the build task in the root folder. If you do not have ssh access to this server, then contact a SilverStripe staff member to update this for you. Make sure that the download link below links to the correct changelog page. E.g. https://docs.silverstripe.org/en/3.2/changelogs/3.2.1/
• Post a release announcement on the silverstripe release announcement google group.
• Create a release announcement forum sticky on the releases and announcements forum category. Make this a global read-only sticky, and un-sticky any older release.
• Update the #silverstripe IRC topic to include the new release version.

See also#

If at any time a release runs into an unsolveable problem contact the core committers on the discussion group to ask for support.

Blue-green deployment, canary release: рецепт приготовления безрисковых релизов

Банковские сервисы по умолчанию не должны падать и ложиться хоть на секундочку, даже (и в особенности) когда мы обновляемся. Ведь всего лишь какие-то секунды могут привести к потерям с множеством нулей. Чтобы этого не произошло мы используем blue-green deployment (BGD).

Простым языком, blue-green deployment — это способ развертывания, который позволяет обновлять приложения, не отклоняя ни одного запроса, без остановок. Как это сделать, расскажу и покажу на одном большом примере. Статья подойдет DevOps-инженерам и бэкенд-разработчикам, особенно на HighLoad-проектах, а также моим будущим коллегам, как методичка по безрисковым релизам, чтобы прод не падал каждые 2 недели по графику релизов (а такое тоже бывало). В статье будет минимум теории и максимум практики.

Дисклеймер: немного о «методичке»

В нашей компании постоянно растет количество сотрудников. Одна из моих функций, как Software Engineering Manager’а, повышение как роста технической и технологической зрелости ребят, так и качества продуктов, разрабатываемых командами. Поэтому мне постоянно приходится повторять тему про BGD.

Реакции бывают разные. Кто впервые слышит, что можно обновлять версии продуктов не останавливая обслуживание, часто восклицают: «А что, так можно было?!». Те же, кто пытается применять впервые на практике, неожиданно для себя сталкиваются с проблемами при реализации и просят как можно подробнее освещать буквально каждый шаг в отдельности.

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

Большинство материалов про blue-green deployment не освещают тему достаточно полно, поэтому многие разработчики так и не берутся за реализацию. Поэтому считаю важным отметить, что в статье отражена «сквозная история» от API, до уровня базы данных.

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

Некоторый код я поместил под спойлеры, чтобы он вас не отвлекал.

Как читать статью:

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

Если решите применить BGD на практике — стоит читать весь текст, да еще и раскрывать спойлеры.

Для тех, кто использует C# и ORM Entity Framework Core, хорошие новости: я написал код примеров так, чтобы вы сразу смогли достичь нужного результата, используя метод copy-paste.

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

Я обещал пример — поехали!

Пример приложения

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

Чтобы не отвлекаться на UI, это будет веб-API приложение.

Исходное состояние: v 1.0

Рассмотрим детально, как устроена программа v 1.0.

Модели.

Модель API v 1.0 и модель EF Core слоя базы данных v 1.0 совпадают

Контекст базы данных.

Я не буду указывать особенности создания контекста базы данных. Предлагаю ознакомиться с этой темой самостоятельно в документации.

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

Не буду описывать механику взаимодействия с БД с помощью EF Core, смотрите соответствующие разделы документации: запросы и изменения.

Миграция v 1.0.

Создание миграции в Visual Studio (PowerShell):

или в командной строке (.NET Core CLI):

Выполнение миграции в Visual Studio (PowerShell):

или в командной строке (.NET Core CLI):

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

В результате выполнения миграции будет создана база данных и таблица со столбцами.

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

Вставка данных приводит к такому виду запроса БД:

Развертывание v 1.0

Примечание: в схемах развертывания я не буду отображать неизменяющиеся свойства Id и FirstName , чтобы сосредоточиться на самом важном.

Сопоставления с БД v 1.0

Версия приложения v 1.0, версия API v 1.0:

Сопоставление моделей API и таблицы БД v1.

Примечание: в таких подразделах я буду указывать схемы сопоставления моделей API и таблицы базы данных, вне зависимости от языка программирования, минуя реализацию бизнес-слоя и механизм используемой ORM.

Когда потребовались доработки…

Я мог бы придумать запрос на изменение каких-либо нетривиальных бизнес-требований, например выбрать именно лучшего работника, а не случайного, но в контексте статьи важнее понять сам принцип. Возьмём наглядный пример: потребуем переименование LastName в Surname .

Классическое решение

Чтобы нагляднее продемонстрировать преимущества предлагаемого метода, сначала рассмотрим, как проходит классический релиз, какие возникают проблемы при его развертывании, а затем — как от них избавиться при помощи blue-green deployment.

В классическом подходе мы переименовываем одно свойство модели на другое.

Модель.

Миграция на основе изменений.

Развертывание. Простое классическое.

Все просто, все знакомо. Но… «Хьюстон, у нас проблемы»

Шесть проблем классического развертывания

У нас возникает проблема остановки сервера для обновления, если сервер простой. А если сложный, включающий в себя микросервисы, то добавляется еще и проблема обновления версии сервера с зависимостями.

Когда мы обновляемся с версии 1 на версию 2, все наши зависимости тоже должны обновиться на новую версию, использующую эту вторую версию.

Классическое развертывание с зависимостями.

Но если что-то пойдет не так, то возникает третья проблема — отказ от новой версии сервера с зависимостями приводит к цепной реакции. Нам придется откатиться полностью.

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

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

Blue-green deployment и canary release

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

Сине-зеленое развертывание (blue-green deployment) — это метод внесения изменений в веб-сервер, приложение или сервер базы данных, путем замены чередующихся промышленных и промежуточных серверов.

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

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

Как это работает

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

Схема blue-green deployment.

В исходном состоянии у нас в доступе синие веб-серверы и база данных.

Blue-green deployment по шагам:

Шаг 1. Мы раскатываем зеленые серверы: размещаем на них новую версию.

Накатываем миграции новой версии на базу данных, но по-прежнему у нас работают синие серверы на предыдущей версии. Проводим тестирование зеленых в штатном режиме.

Шаг 2. Переключаем балансировщик на зеленые серверы. Если все хорошо — отключаем синие серверы.

Теперь взглянем на канареечный релиз.

Canary release по шагам.

Ничего сложного: все то же самое, но только после внутреннего тестирования или вместо него, мы балансировщиком постепенно распределяем нагрузку между синими серверами со старой версией и зелеными с новой, вплоть до 100%.

Рецепт приготовления

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

Примечание для разработчиков на C#, использующих ORM Entity Framework Core: На первый взгляд может показаться, что реализация проста, но на основе массы проведенных экспериментов, могу уверенно сказать, что это не так. В EF Core есть ряд соглашений и различных настроек сопоставлений. Например, если объявить поле не так, как надо, или неверно прописать PropertyAccessMode при конфигурировании ModelBuilder, то результат может неприятно удивить. Из всех возможных вариантов я подобрал самый простой с минимумом кода и рекомендую использовать проверенный мной подход или же тщательно проверять результаты, если выберете иной способ реализации.

Примечание: все протестировано на .Net 6.0 и актуальной сейчас версии EF Core 6.0.5.

Этап 1: релиз приложения версии 2.0

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

Реализация модели слоя данных.

Миграция на основе изменений.

Этап 1: развертывание v 2.0

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

Шаг 1. На прошлом этапе приложение версии v 1.0 было развернуто на группе синих серверов, поэтому новую версию v 2.0 разворачиваем на группу зеленых серверов. База данных находится в версии v 1.0.

Развертывание приложения v 2.0

Шаг 2. Выполнение миграции, которое добавляет поле базы данных Surname , допускающее значения null .

Развертывание приложения v 2.0. Миграция

Шаг 3. Теперь можно приступать к финальному тестированию новой версии v 2.0, которая поддерживает API v 1.0 и v 2.0 одновременно.

Развертывание приложения v 2.0. Тестирование

Шаг 4. Затем переключаем балансировщик. Это можно делать разом или долями — канареечный релиз в действии.

Развертывание приложения v 2.0. Переключение балансировщика

Если что-то пошло не так, то балансировщик переключает 100% нагрузку обратно на прежнюю версию приложения v 1.0, а версию v 2.0 дорабатывают, тестируют и снова разворачивают на зеленые серверы.

Развертывание приложения v 2.0. Обратное переключение балансировщика.

Шаги 1, 3 и 4 повторяются столько, сколько требуется, при этом выполнение миграции (шаг 2) повторять не имеет смысла. В итоге достигается стабильно работающая версия приложения v 2.0 и принимает 100% входящих запросов.

Развертывание приложения v 2.0. Стабилизация новой версии

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

Потребители API v 1.0 уведомляются о необходимости перехода на новую версию API v 2.0. Это будет промежуточный этап, когда часть потребителей будет использовать API v 1.0, а другая часть уже перейдет на использование API v 2.0.

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

Этап 1: сопоставления с БД v2.0

Посмотрим, как описанный процесс будет исполняться «под капотом» после выполнения миграции БД, которая в результате перейдет в версию v 2.0.

Версия приложения v 1.0, версия API v 1.0:

Сопоставление моделей API v 1.0 приложения v 1.0 и таблицы БД v2

Как видно приложение v 1.0 ничего «не знает» о поле Surname и оно приобретает значения null .

Версия приложения v 2.0, версия API v 1.0:

Сопоставление моделей API v 2.0 приложения v 1.0 и таблицы БД v2

В этом случае основное поле — LastName , а поле Surname — дублер.

Версия приложения v 2.0, версия API v 2.0:

Сопоставление моделей API v 2.0 приложения v 2.0 и таблицы БД v2

Здесь тоже поле Surname — просто дублер LastName .

Этап 2: релиз приложения версии 2.1

На этом этапе значения колонки Surname назначаются равными соответствующим значениям колонки LastName , если это не сделали раньше. Колонка Surname становится обязательной для заполнения, а вот LastName наоборот — будет необязательной, допускать значения NULL .

В результате поля меняются ролями: Surname будет основным, а LastName — дублером. В коде приложения заменяем использование LastName на Surname , LastName при этом помечаем устаревшим.

Если к этому моменту не все потребители переключились на API v 2.0, то мы можем продолжать поддержку API v 1.0 в этой версии. Рассмотрим именно такой случай, поскольку чаще всего такое переключение происходит не быстро.

Реализация модели слоя данных.

Миграция.

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

Примечание. Предполагается, что эта миграция будет выполняться быстро, в противном случае, нам пришлось бы присваивать значения партиями.

Этап 2: развертывание v 2.1

Поскольку при предыдущем релизе были использованы зеленые серверы, теперь новую версию будем развертывать на освободившиеся ранее синие серверы.

Шаги будут идентичными.

Промежуточные шаги развертывания v 2.1.

Шаг 1. Развертывание новой версии.

Развертывание приложения v 2.1

Шаг 2. Миграция.

Развертывание приложения v 2.1. Миграция

Шаг 3. Тестирование.

Развертывание приложения v 2.1. Тестирование

Шаг 4. Эксплуатация приложения версии 2.1

Развертывание приложения v 2.1. Переключение балансировщика

Этап 2: сопоставления с БД v2.1

В этом подразделе все тоже предсказуемо. Оставлю видимым функционал, наиболее близкий к целевому.

Сопоставления.

Версия приложения v 2.0, версия API v 1.0:

Версия приложения v 2.0, версия API v 2.0:

Версия приложения v 2.1, версия API v 1.0:

Версия приложения v 2.1, версия API v 2.0:

Сопоставление моделей API и таблицы БД v1

Этап 3

На этом этапе мы отказываемся от чтения/записи значений в колонку LastName . API v 1.0 все еще можно поддерживать, но в примере будем считать, что все потребители уже переключились на API v 2.0 и поддержкой предыдущей версии можно пренебречь.

Реализация модели слоя данных.

Примечание: Я не нашел качественного способа удалить свойство из класса без игнорирования удаления колонки базы данных при генерации миграции. Поэтому могу посоветовать лишь нарушить подход code first и не создавать миграцию в рамках выпуска этой версии.

Этап 3: развертывание v 3.0

Поскольку при предыдущем релизе были использованы синие серверы, теперь новую версию будем развертывать на освободившиеся зеленые серверы.

Шаг 1. Развертывание новой версии.

Развертывание приложения v 3.0

Шаг 2. Ввиду отсутствия миграции шаг 2, его содержащий, отсутствует.

Шаг 3. Тестирование.

Развертывание приложения v 3.0. Тестирование

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

Шаг 4. Эксплуатация приложения версии 3.0.

Развертывание приложения v 3.0. Переключение балансировщика

Этап 3: сопоставления с БД v 2.1

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

Версия приложения v 3.0, версия API v 2.0:

Сопоставление моделей API и таблицы БД v1

Этап 4

Генерация финальной миграции — удаление столбца LastName из базы данных.

Реализация v 1.0.

Миграция на основе изменений.

Этап 4: развертывание v 4.0

Шаг 1. Развертывание новой версии.

Развертывание приложения v 4.0

Шаг 2. Миграция.

Развертывание приложения v 4.0. Миграция

Шаг 3. Тестирование.

Развертывание приложения v 4.0. Тестирование

Шаг 4. Это финальная версия приложения. Мы достигли поставленной задачи!

Развертывание приложения v 4.0. Переключение балансировщика

Этап 4: сопоставления с БД v 3

Версия приложений v 3.0 и v 4.0, версия API v 2.0 — сопоставления совпадают:

Сопоставление моделей API и таблицы БД v 1

Шпаргалка для бэклога

Здесь сводка того, что мы сделали (а мы много чего сделали), по выполненным шагам.

У нас имелось приложение версии 1.0 с БД версии v 1.0 (столбец с наименованием LastName ).

Развернуто приложение версии v 2.0.

Добавлена поддержка API целевой версии v 2.0.

Потребителям предлагается начать переход с API версии v 1.0 на версию v 2.0.

Данные сохраняются в столбцы LastName и Surname , где Surname — это поле-дублер.

Приложение всегда читает из столбца LastName .

Примечание: Surname не имеет ограничения NOT NULL . БД версии v 2.0.

Развернуто приложение версии 2.1.

Поддержка API версии 1.0 в этом релизе может быть продлена.

БД все так же содержит оба столбца LastName и Surname .

Столбец Surname — копия столбца LastName , но они поменялись ролями, теперь LastName — поле-дублер.

Приложение всегда читает из столбца Surname .

Примечание: Surname имеет ограничение NOT NULL , а LastName теперь его не имеет. БД версии v 2.1.

Развернуто приложение версии v 3.0, которое сохраняет данные только в столбец Surname и читает из Surname .

Столбец LastName сохранен только для обратной совместимости и не используется.

Поддержка API версии v 1.0 еще возможна, но уже прекращена.

Примечание: БД по-прежнему имеет версию v 2.1.

Развернуто приложение версии v 4.0.

Финальная миграция приводит БД к версии v 4.0, в которой завершен переход от LastName к Surname и удален столбец LastName .

Поддержка API версии v 1.0 еще возможна, но уже нецелесообразна.

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

Но если все свести к самому минимуму, то мы сделали 4 простых действия:

добавили поле-дублер и новую версию API v 2.0;

перенесли данные из исходного в дублер и поменяли их ролями;

отменили поддержку старого API версии v 1.0;

удалили старое поле.

С точки зрения организации и контроля последовательности шагов это будет работать так же, как шпаргалка.

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

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

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

Конец. Цели достигнуты!

Подведем итоги:

Остановки серверов для обновления нет. Как в самом начале, так и в случае откатов.

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

Цепной реакции из-за отказа новой версии с зависимостями больше нет.

Нет нужды использовать резервную копию БД.

Нет простоя при откате на предыдущую версию.

Нет потерь данных. Ведь мы не откатывали БД на устаревшую резервную копию.

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

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

Core Release

When Eve enters Awakening Mode, Eve goes into Core Release mode and materializes the Queen’s Core. The Queen’s Core will follow Eve and react to help Eve by changing during offensive and defensive situations.

Queen’s Core

In Core Release mode, every successful command or Active hit or Special Active skill use will charge up the Queen’s Core. Once it appears at a certain charge, you can see when it reaches the next stage when the core flashes for a brief moment as it starts to shine brighter. The higher the level of the core, the more damage will be dealt when it fires and the more times it will be able to defend Eve from attacks.

Queen’s Shield

When Eve is attacked from the front on the ground while Queen’s Core is active, the core will switch to defense mode and cover Eve in a shield that absorbs a portion of the damage. While the core covers Eve in the Shield, pressing will allow Eve to phase back from the target in the same manner as Photon Flash. The core loses a level after defending. However, if you are continuously attacked, the core will only lose its level once the defending sequences stop.

Queen’s Laser

When Eve uses an Active or Special Active and hits a target, the Queen’s Core switches to offense mode and fires a blue laser at a target. The laser does multiple hits and will not knock down. The laser will lock on to the nearest target and track that target until all hits are dealt. The damage of the laser done depends on the core’s level.

The lasers will fire the moment the skill lands a successful hit and the target does not die on that hit. Certain skills will not cause the laser to fire immediately however. Illusion Stinger will only trigger the laser once an explosion hit connects, not when the spears do. Sonic Wave, Heaven’s Fist — Sweeper, and Surface Cutting will only fire the laser at the end of the skill. Some skills will also not trigger Queen’s Laser, such as Heaven’s Fist — Pressure.

At level 3 Awakening, a Powerful Queen’s Core is created. Unlike the normal Queen’s Core, the Queen’s Laser fired by this core will be colored red and can deal splash damage to groups of enemies. In addition, if the target is moved while they are being hit by the laser, the Powerful Queen’s Core will adjust its trajectory to lock onto the target.