Improving throughput, with continuous release management
Blaze uses a Mono Repo structure which means any 'plugins' can be developed alongside core code, by any developer working within the Blaze framework. Developers manage dependencies between the core application and plugins using Lerna, allowing Blaze developers to keep versions in sync, when changing dependencies. Plugins can therefore be managed and developed independently, giving flexibility by virtue of the de-coupled architecture.
Blaze developers can follow Byte9’s process of using conventional commits, allowing for automation of version numbers and changelogs depending on what has been updated within the applications. After versions are increased, developers can then use Lerna to automatically publish the packages to the NPM registry where different Blaze installations can consume them.
Byte9’s release management process facilitates fast paced, concurrent releases to Blaze applications; the CMS administration, the API framework and the front-end Blaze React application. These are updated as the framework is updated in real-time, not in large changes that take place periodically, which is the traditional approach to updating legacy software.
By being able to create on-demand environments for releases, using Terraform and Github Actions, different branches can be tested concurrently, making development of different features and functionality easy, by preventing bottlenecks. Environments for this are created only when required within Cloud providers (like AWS, Google Cloud or Azure), using Terraform managing 'infrastructure as code' , again reducing operational cost of development and testing ongoing.
Managing code quality, using automated testing
The Byte9 Dev team follow Test Driven Development methodologies (TDD). Testing is not so much a 'Strategy’ as the 'Status Quo' for developers of the Blaze framework. Blaze automates tests in a sequence of steps from the Continuous Integration (CI) / Continuous Delivery (CD) Platform as well as locally, for development.
The steps are as follows:
Code linting - we have created a rule set of best practices across different languages and technologies e.g., TypeScript, JavaScript, React etc, used within Blaze. A code linter processes code in development, looking for common code issues, best practices. The lint must be passed in order to enter the Unit Testing process.
Unit Testing - each area of functionality has a ‘test suite’ created using Jest where we aim for 100% coverage across all code. When creating unit tests, developers can mock the required system data, in order to have lots of efficient tests that resemble real-world usage. Once unit tests pass, Functional testing follows.
Functional Testing - where devbelopers use integration testing in the form of Puppeteer & Jest Snapshots in order to check services are responding in the expected way and in the corrcet format. After this is complete the Blaze CI / CD platform moves onto the User Interface (UI) Visual Regression Resting.
Visual/UI Regression testing - At this stage we programmatically compare and store visual snapshots of pages before and after, looking for user interface 'breaking changes' in simulations of different modern web browsers, using Playwright.
Delivering infrastructure, for continuous system improvement
Blaze production, immutable deployment and automated testing tooling and process supports continuous integration and continuous delivery of functional, tested software. The outcome of this is continuous improvements with deployments being made semi-autonomously, if required (e.g. JavaScript package dependency updates).
The benefit of the Blaze framework’s progressive CI & CD tooling and process is that the Blaze continuously improves and that any changes brought about by the many dependencies within the technology stack can be tested and deployed as they are released, on a daily basis, by distributed and autonomous development teams working on within the Blaze framework.