diff --git a/blog/2024-08-20-intro-quality-engineering-blog.md b/blog/2024-08-20-intro-quality-engineering-blog.md index 4f78549..8c6ddda 100644 --- a/blog/2024-08-20-intro-quality-engineering-blog.md +++ b/blog/2024-08-20-intro-quality-engineering-blog.md @@ -2,13 +2,17 @@ slug: intro-quality-engineering-blog title: Intro Quality Engineering Blog authors: [dorin] -tags: [] +tags: [Introduction] --- +Welcome to IOG Quality Engineering blog + ## Welcome to the Quality Engineering Odyssey! Hello passionate tech enthusiasts, software crafters, and quality advocates! Welcome to our humble abode in the vast digital world – The Quality Engineering Blog. If you’ve found your way here, chances are you’re as obsessed with software quality as we are. But if you're new to the term, fret not! This space is for both newcomers and veterans alike. + + ## Quality is Not an Accident Software quality isn't something that just happens. It’s an intricate ballet of collaboration, taking place across various stages of the Software Development Life Cycle (SDLC). From ideation to deployment, every step requires keen attention, collaboration, and an undying commitment to excellence. This is where Quality Engineering comes in. diff --git a/blog/2024-11-22-release-readiness-checklist.md b/blog/2024-11-22-release-readiness-checklist.md new file mode 100644 index 0000000..eb4aec1 --- /dev/null +++ b/blog/2024-11-22-release-readiness-checklist.md @@ -0,0 +1,46 @@ +--- +slug: release-readiness-checklist +title: 'Release Readiness Checklist: A Success Story at IO' +authors: [dorin] +tags: [Release Strategy] +--- + +Release checklist IOG image + +Input | Output (IO) is committed to delivering high-quality software that meets the evolving needs of its users. But achieving a smooth and successful product launch requires more than just great code. It demands a meticulous approach to ensure every aspect is thoroughly vetted before release. That's where the Release Readiness Checklist comes in. This powerful tool has become a cornerstone of the release management process, helping teams across the organization achieve greater transparency, reduced risk, and increased efficiency. + + + +## Why a Release Readiness Checklist? + +IO recognizes that the transition from development to deployment is a crucial stage in delivering high-quality software. The checklist is designed to ensure that every step in this transition has been thoroughly completed, validated, and documented before the product goes live. By following this structured approach, teams minimize risks, ensure alignment across all stakeholders, and increase confidence in every release. + +## Key benefits + +- **Clarity and transparency**: The checklist keeps all teams aligned by clearly outlining what needs to be verified, making the release process transparent and easier to manage. + +- **Risk mitigation**: By identifying and addressing potential issues early on, the checklist helps prevent costly post-release fixes and last-minute changes. + +- **Quality assurance**: The checklist helps ensure that all features, functionalities, and non-functional requirements meet predefined quality standards and acceptance criteria, maintaining high product quality. + +- **Operational readiness**: Verifying that infrastructure updates, deployment plans, and other operational elements are in place helps facilitate a smooth and disruption-free release. + +- **Clear accountability**: Each section of the checklist is assigned to an owner. This promotes thorough reviews and accountability for every component of the release, and helps ensure that every release receives the necessary attention and expertise before going live. + +- **Effective stakeholder communication**: The checklist promotes ongoing communication with stakeholders, keeping everyone aligned with the release process, minimizing surprises, and ensuring clear responsibility. + +## Key features + +### Clear roles and responsibilities + +The checklist is designed to promote clear accountability and collaboration throughout the release process. It divides responsibilities among relevant stakeholders to ensure that no aspect of a release is overlooked. Each section of the checklist has a designated owner (typically, the leader of each team involved) who is responsible for completing the checks and providing sign-off. This approach provides the necessary attention and expertise to each release before going live. + +### Evidence-based for transparency and trust + +An evidence-based approach means that all checks are not just marked as complete but are backed by verifiable proof, such as open issues, test results, or security audits. This evidence is documented within the checklist itself, providing a clear and accessible record of the verification process. This approach increases transparency and accountability across teams, building trust among stakeholders and ensuring everyone is aligned before a release. + +## Conclusion + +The Release Readiness Checklist has transformed the way IO approaches software releases. By providing a clear framework and promoting collaboration, it has significantly improved efficiency, reduced risks, and enhanced product quality. Ultimately, the checklist empowers teams to deliver software they can be proud of, knowing that every aspect has been thoroughly vetted and validated. + +Curious about what else goes into a successful release? Explore the full checklist and [the checklist template](/docs/knowledge-hub/checklists-and-templates/release-readiness-checklist-template). diff --git a/blog/tags-sidebar-data.json b/blog/tags-sidebar-data.json new file mode 100644 index 0000000..58cafdd --- /dev/null +++ b/blog/tags-sidebar-data.json @@ -0,0 +1,12 @@ +[ + { + "label": "Quality Strategy", + "permalink": "/quality-strategy", + "description": "Quality Strategy tag" + }, + { + "label": "Release Strategy", + "permalink": "/release-strategy", + "description": "Release Strategy tag" + } +] diff --git a/blog/tags.yml b/blog/tags.yml index ca98785..653f0f3 100644 --- a/blog/tags.yml +++ b/blog/tags.yml @@ -1,4 +1,9 @@ -quality-strategy: - label: Quality Strategy - permalink: /quality-strategy - description: Quality Strategy tag +intro: + label: Introduction + permalink: /intro + description: Introduction tag + +release-strategy: + label: Release Strategy + permalink: /release-strategy + description: Release Strategy tag diff --git a/docs/knowledge-hub/Checklists & templates/01-release-readiness-checklist.md b/docs/knowledge-hub/Checklists & templates/01-release-readiness-checklist.md new file mode 100644 index 0000000..f70c936 --- /dev/null +++ b/docs/knowledge-hub/Checklists & templates/01-release-readiness-checklist.md @@ -0,0 +1,48 @@ +--- +title: Release Readiness Checklist Template +metaTitle: Release Readiness Checklist Template +slug: /knowledge-hub/checklists-and-templates/release-readiness-checklist-template +--- + +The purpose of this Release Readiness Checklist is to ensure that new functionalities are thoroughly verified and validated before being released to the end users. + +This Release Readiness Checklist is intended as guidance, so it may not cover all potential issues or considerations. Always take into account the unique requirements and constraints of your specific project. + +**Note**: All the following operations are executed on the software version that is set for release: + +- Product version: +- Code version (commit/tag): +- Date: +- Release notes link: +- New functionalities link: +- List of impacted GitHub repos: +- Compatibility matrix link: + +| Area | Details | Owner / Approver | Status | Comments / Evidence | +|:---------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------|:-------|:--------------------| +| Engineering / New functionalities | Feature completion: All planned features for this release have been completed.
Code coverage: All new code is thoroughly validated and covered by low-level tests (unit, property, component, and integration).
Code security: The new code is free of security vulnerabilities and does not introduce any security risks to the application or user data.
Automated tests: Automated unit and integration tests are in place and pass successfully. | Engineering lead | | | +| Engineering / Regressions | Regression testing: All existing functionalities, key flows, and low level tests have been executed and confirmed to work correctly.
Performance testing: There are no performance degradations in this release, when compared with previous releases.
Database & infrastructure changes: Any database or infrastructure changes are tested, and ready. | Engineering lead | | | +| Test engineering / New functionalities | Feature completion: All planned features for this release have been completed and have passed the final product validation, including e2e testing, UAT, exploratory, and sync testing across all supported platforms and devices.
Full traceability is established between each feature, its user stories, acceptance criteria, and corresponding system-level test results, demonstrating that all requirements are met.
End-to-end tests, including edge and corner cases, have been conducted and passed successfully.
All functional and non-functional requirements have been successfully validated.
Usability testing: The user interface and user experience are consistent and intuitive.
Exploratory testing: Exploratory testing has been conducted and has passed successfully.
UAT: User Acceptance Testing has been completed and approved. | Test engineer lead | | | +| Test engineering / Regressions | Regression testing: Automated regression testing has been performed to ensure existing functionalities are not broken.
Performance testing: There are no performance degradations in this release when compared with previous releases. | Test engineer lead | | | +| Security | Code security: Code is free of known security vulnerabilities as verified by automated scans and manual reviews.
Product security: Security tests have been conducted to ensure new features don't expose any security vulnerabilities.
Compliance: The new features comply with relevant legal and regulatory requirements.
Audits: All planned audits were finalized and passed. | Security lead | | | +| Product management | Feature completion: All planned features for this release have been completed and satisfy the acceptance criteria. | Product lead | | | +| Delivery | Bug resolution: All reported bugs categorized as 'blockers' or 'critical' have been resolved. Any 'major' remaining bugs are understood and accepted.
Risk management: All risks are analyzed and addressed (ie accept, mitigate, transfer).
Dependency management: All dependencies have been assessed and their status updated ('done,' 'canceled,' or 'not required').
Pre-production validation: The code version was deployed and fully validated in a pre-production environment that replicates the production environment as closely as possible.
Deployment schedule: The deployment is scheduled for a time that minimizes risk and impact on users.
Release notes: Release notes are prepared, highlighting the new functionalities, bug fixes, and known issues.
Documentation: All relevant documentation (including user guides, API references, release notes, etc.) is updated to reflect the changes in the new release.v
Known issues, limitations, and breaking changes are clearly documented in the release notes and relevant documentation. | Delivery lead | | | +| Operations | Update procedures: All procedures for updating the production environment (including environment readiness, configurations, rollback plans, etc.) have been reviewed and are ready for execution.
Rollback plan: A robust and tested rollback plan is in place in case of issues during deployment or post-release.
Monitoring tools and knowledge: The Operations team has the necessary monitoring tools in place, along with the knowledge and understanding of the new functionalities, to effectively track their performance and stability after deployment. | SRE/DevOps lead | | | +| Legal | Communication review: All planned communication is approved by the Legal department. | Legal representative | | | +| Marketing, Comms | Internal communication: Internal teams and stakeholders are informed about the upcoming release and its impact.
External communication: Marketing materials for external audiences (eg customers or press) are prepared to be distributed through appropriate channels. | Marketing lead | | | +| Customer support | Support readiness: The support team is prepared to provide immediate support related to the new version. | Customer support lead | | | + +**Legend:** +- **Status** + - in progress (work still needs to be done) + - done/success + - done/fail + - N/A: This item cannot logically apply. + - WAIVED: This item could apply, but the stakeholders deem it unimportant. +- **Evidence** + - link to evidence that supports the status + - link to test results report + - link to bug reports + - link to metrics +- **Comments** + - are there any limitations, known risks, etc? diff --git a/src/components/BlogTagsSidebar.tsx b/src/components/BlogTagsSidebar.tsx new file mode 100644 index 0000000..2080c53 --- /dev/null +++ b/src/components/BlogTagsSidebar.tsx @@ -0,0 +1,42 @@ +import Link from '@docusaurus/Link'; +import React, { useState, useEffect } from 'react'; +import { useHistory, useLocation } from 'react-router-dom'; + +type Tag = { + label: string; + permalink: string; + description?: string; +}; + +type BlogTagsSidebarProps = { + tags: Tag[]; +}; + +const BlogTagsSidebar: React.FC = ({ tags }) => { + const { pathname } = useLocation(); + + return ( +
+
Filter by Tags
+ +
+ ); +}; + +export default BlogTagsSidebar; diff --git a/src/css/custom.css b/src/css/custom.css index 47b5ed5..c8c67b9 100644 --- a/src/css/custom.css +++ b/src/css/custom.css @@ -264,3 +264,56 @@ div:has(> .dsla-search-wrapper) { box-shadow: none; padding: 20px 10px !important; } + +.tags-dropdown-container { + font-family: inherit; + font-size: 0.9rem; + border-top: 1px var(--ifm-font-color-base) solid; + padding-top: 1rem; +} + +.tags-dropdown-wrapper { + width: 100%; + padding: 0.2rem 0.5rem; + border-radius: 2px; +} + +.tags-dropdown { + width: 100%; + list-style: none; + padding-left: 0; + border: none; + font-size: 0.9rem; + margin: 0 0 var(--ifm-list-margin); +} + +.tags-dropdown li { + margin-top: 0.7rem; +} + +.tags-dropdown a { + color: var(--ifm-font-color-base); +} + +.tags-dropdown a:hover { + text-decoration: none; + color: var(--ifm-link-color); +} + +.tags-dropdown a[aria-selected='true'] { + color: var(--ifm-link-color); +} + +.tags-filter-heading { + font-size: var(--ifm-h4-font-size); + font-weight: var(--ifm-font-weight-bold); + margin-bottom: 1rem !important; +} + +@media (max-width: 996px) { + .tags-dropdown-container { + margin-top: 1.2rem; + padding-top: 1.5rem; + padding-left: 1rem; + } +} diff --git a/src/theme/BlogSidebar/Content/index.tsx b/src/theme/BlogSidebar/Content/index.tsx new file mode 100644 index 0000000..15db9d2 --- /dev/null +++ b/src/theme/BlogSidebar/Content/index.tsx @@ -0,0 +1,60 @@ +import React, { memo, useEffect, useState, type ReactNode } from 'react'; +import { useThemeConfig } from '@docusaurus/theme-common'; +import { groupBlogSidebarItemsByYear } from '@docusaurus/plugin-content-blog/client'; +import Heading from '@theme/Heading'; +import type { Props } from '@theme/BlogSidebar/Content'; + +import tagsData from '@site/blog/tags-sidebar-data.json'; +import BlogTagsSidebar from '@site/src/components/BlogTagsSidebar'; + +function BlogSidebarYearGroup({ + year, + yearGroupHeadingClassName, + children, +}: { + year: string; + yearGroupHeadingClassName?: string; + children: ReactNode; +}) { + return ( +
+ + {year} + + {children} +
+ ); +} + +function BlogSidebarContent({ items, yearGroupHeadingClassName, ListComponent }: Props): ReactNode { + const themeConfig = useThemeConfig(); + + const [tagsArray, setTagsArray] = useState([]); + + useEffect(() => { + const tagsArray = Object.entries(tagsData).map(([key, value]) => ({ + label: value.label, + permalink: value.permalink, + description: value.description, + })); + setTagsArray(tagsArray); + }, []); + + if (themeConfig.blog.sidebar.groupByYear) { + const itemsByYear = groupBlogSidebarItemsByYear(items); + return ( + <> + {itemsByYear.map(([year, yearItems]) => ( + + + + ))} + + + ); + } else { + return ; + } +} + +export default memo(BlogSidebarContent); diff --git a/static/img/blog/001-intro-blog-post.png b/static/img/blog/001-intro-blog-post.png new file mode 100644 index 0000000..ced8f48 Binary files /dev/null and b/static/img/blog/001-intro-blog-post.png differ diff --git a/static/img/blog/002-release-readiness-checklist-post.png b/static/img/blog/002-release-readiness-checklist-post.png new file mode 100644 index 0000000..c7a3f02 Binary files /dev/null and b/static/img/blog/002-release-readiness-checklist-post.png differ