SDK-4673: Integration of Code Releases into your project repository

docs/scu/dev/features/autointegration-of-spryker-module-releases.md

@@ -0,0 +1,43 @@
+---
+title: Integration of Code Releases into your project repository
+description: How Spryker Code Upgrader automatically integreates code releases into your code base
+template: concept-topic-template
+---
+
+# Challenges of integrating Spryker Code Releases
+
+Spryker architecture provides extensibility of different modules by using extension points in the project code.
+With Spryker Code Upgrader, the process of integrating plugins, configuration updates, adding new translations, and other code changes is automated.
+As the result the manual step can be skipped when engineers have to understand and apply code changes by themselves in order to add new features in the project.
+
+Supported extension points:
+- Configuration
+  - Module
+  - Environment
+- Copying module files
+- Adding/Removing
+  - Plugin
+  - Navigation element
+  - Widget
+  - Glue relationship
+- Adding
+  - Transfer definition
+  - DB schema definition
+
+# What is a release rating
+The release rating is a measure of the integrability coverage of each Spryker release, representing the percentage of automatically integratable plugins, configurations, schemas, and other components.
+This rating is determined during internal testing, where the generated integration code is compared with the manually released code to assess the level of integration achieved. If both are equal, then the release is fully integratable.
+
+There are some kind of releases that provide only dependency updates without any code integrations (so called module-only releases). Such releases have 100% coverage.
+
+The rating for each suggested release can be found in the Upgrader pull request description.
+
+# How to enable and configure
+By default, the Integrator is enabled. It applies integrations of releases with rating 70% or more (this threshold can be configured through the spryker CI configuration).
+
+It is important to note that after the integration process is completed, a style fixer is applied to the changed files. It's recommended for the project to have its own style fixer to expose project-specific code style conventions.
+
+# What to do if you see a generated code, that is not valid
+1. Make sure that your project code follows the Upgradability Guidelines and passes the [Evaluator check](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html).
+2. You can try manually correcting the generated code as a quick fix.
+3. If none of the above solutions work, please contact us for further assistance.

docs/scu/dev/features/security-upgrades.md

@@ -0,0 +1,54 @@
+---
+title: Handling Security Releases by Spryker Code Upgrader
+description: How Spryker Code Upgrader works with releases related to known security vulnerabilities
+template: concept-topic-template
+---
+
+Being on top of security releases of your vendor or 3rd-parties is very crusial:
+* *Vulnerability Mitigation*: Security updates often address known vulnerabilities or weaknesses in software. Installing these updates promptly helps to mitigate these vulnerabilities, reducing the risk of unauthorized access, data breaches, or malicious activities.
+* *Enhanced Protection and risk mitigation*: Security updates typically include patches and improvements that enhance the overall security of the system.
+* *Regulatory Compliance*: Many regulatory bodies require organizations to maintain up-to-date security measures, which often includes installing security updates promptly. Compliance with these regulations not only reduces legal and financial risks but also helps to maintain a positive reputation and trust with stakeholders and customers.
+
+# What kind of security releases covered?
+
+The static code analysis tools provide the capability to detect various known vulnerabilities.
+
+These tools assist in identifying and preventing potential security risks from these sources:
+1. Spryker Security releases
+2. PHP Ecosystem
+3. NPM Ecosystem
+
+## Spryker Security releases
+
+Security release is a type of release that aims to deliver a security vulnerability fixes, rather than introducing new features or functionalities.
+The example of security release is [https://api.release.spryker.com/release-group/4753](https://api.release.spryker.com/release-group/4753)
+
+The security releases are applied alongside other releases, but the security release is being prioritized and delivered first, ensuring the fast delivery of critical security updates.
+
+Automatic installation of security releases is only available between the major version releases. However, the major releases require manual installation, similar to all major releases.
+
+[Evaluator analysis tool](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html) can be used to detect if there are any security fixes available for the Spryker modules in your project.
+It has the corresponding [Spryker security checker](docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-security-checker.md) for that.
+
+## PHP Ecosystem
+The PHP ecosystem refers to everything related to the PHP code, which includes the Spryker PHP conventions and rules.
+
+To detect violations related to it [Evaluator analysis tool](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html) can be used.
+
+The Evaluator checkers responsible for that:
+- [Additional logic in dependency provider checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/additional-logic-in-dependency-provider.html)
+- [Container set function checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/container-set-function.html)
+- [Dead code checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/dead-code-checker.html)
+- [Minimum allowed shop version checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/minimum-allowed-shop-version.html)
+- [Multidimensional array checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/multidimensional-array.html)
+- [Open-source vulnerabilities checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/open-source-vulnerabilities.html)
+- [PHP versions checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/php-version.html)
+- [Plugin registration with restrictions checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/plugin-registration-with-restrintions.html)
+- [Single plugin argument checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/single-plugin-argument.html)
+- [Spryker dev packages checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/spryker-dev-packages-checker.html)
+- [Upgradability guidelines checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/upgradability-guidelines.html)
+
+## NPM Ecosystem
+The NPM ecosystem refers to everything related to the packages and tools available through the NPM.
+
+NPM violations can be detected by [Evaluator analysis tool](/docs/scos/dev/guidelines/keeping-a-project-upgradable/run-the-evaluator-tool.html) with the corresponding [NPM checker](/docs/scos/dev/guidelines/keeping-a-project-upgradable/upgradability-guidelines/npm-checker.html) for that.

docs/scu/dev/features/upgrade-verification.md

@@ -0,0 +1,30 @@
+---
+title: Active detection of incompatibilies
+description: How Spryker Code Upgrader actively detects and warns you when your code becomes incompatible with the code in upgraded modules
+template: concept-topic-template
+---
+
+It is very important for Spryker Code Upgrader to ensure stability of the upgrades. On the one hand you have your automated tests that you rely on, those tests are run in your CI system and you use them before you merge the pull request created by Spryker Code Upgrader. On the other hand and in addition we run a number of code checks to offer an early warning system even without having a full context or knowledge of your project.
+
+# Validations and warnings
+
+The upgrader offers validations ensure the accuracy and safety of the upgrade process.
+The warnings provide guidance on potential risks or necessary actions for a successful upgrade.
+
+Warning types:
+- Major code releases warning.
+  All the major releases should be installed manually to integrate the BC breaks.
+- PHP Broken Files.
+  Phpstan checks project code after each release application and provides corresponding warnings.
+- Conflict between project class, which extends a private class in a Spryker module, and a changes made by Spryker in their latest release.
+  To resolve this conflict you need to re-write the custom class with the necessary changes.
+- Module name conflict warnings.
+  Custom project module has the same name with spryker released module and should be renamed.
+- Release integration warnings (warnings related to the integration process)
+- Upgrader warnings (warnings related to the upgrader process)
+
+# What to do when you see these warnings in the PR?
+
+In most cases, warnings come with specific information that helps you identify the class or file needed to fix the issue.
+Most of these issues are easily fixable in your IDE.
+