SurveyJS Software Development Lifecycle (SDLC) Policy

Updated: 8/25/2025
Current version: 2.3.3

This policy defines the processes and practices governing the design, development, testing, release, deployment, and maintenance of SurveyJS products. The policy ensures that software is delivered with high quality, maintainability, security, and backward compatibility. It applies to all team members contributing to design, development, testing, release, and support.

This policy applies to all SurveyJS products, including:

It encompasses all phases of the software development lifecycle, from requirements gathering and planning through design, development, testing, release, deployment, and ongoing maintenance. This policy is reviewed annually or when significant changes are introduced.
To report any non-compliance, please email us at info@devsoftbaltic.com or contact us through the Help Desk.

Features, bugs, and improvements are tracked via GitHub Issues. For example, the survey-library repository alone has over 5,600 closed issues. Security-related issues are handled through responsible disclosure and are tracked until resolution. Labels and milestones are used to prioritize and organize work across releases. The product roadmap guides major feature development and release planning. All requirements are documented in issues before development begins.

Design

SurveyJS follows a modular architecture, separating core logic from framework-specific UI rendering. SurveyJS Form Library uses a core module survey-core that encapsulates the data model, question logic, validation, expressions, theming, and more—independent of any UI framework. Framework-specific UI packages (e.g., survey-react-ui, survey-angular-ui, survey-vue3-ui, survey-js-ui) consume the core logic to render surveys and forms. The Survey Creator follows a similar structure: a framework-agnostic core survey-creator-core plus rendering packages for each supported UI framework.

The design pattern of abstracting survey logic into a framework-independent core ensures maintainability, consistent functionality across frameworks, and promotes code reuse. Design decisions adhere to established coding standards and use TypeScript to enforce type safety, maintainability, and clarity.

SurveyJS follows a structured and collaborative development process to ensure code quality, security, and maintainability across all repositories.

All source code is hosted in public GitHub repositories under SurveyJS. Each product—Form Library, Survey Creator, Dashboard, PDF Generator—is maintained in its own GitHub repository:

Development is conducted via GitHub repositories, with all code changes implemented through feature branches forked from the main branch. Direct commits to the main master branch are restricted. Every change is submitted through a pull request, which must undergo peer review by at least one other contributor. Automated CI/CD pipelines enforce build, linting, unit, functional, end-to-end, visual regression, and accessibility tests. Pull requests must be rebased against the latest main branch before merge to ensure consistency and traceability. This structured workflow guarantees that all changes meet quality and security standards prior to integration into the main codebase.

SurveyJS products undergo comprehensive automated and manual testing to ensure quality, security, and accessibility before each release. Testing is integrated into our development lifecycle and enforced via continuous integration (CI) pipelines.

Unit and functional tests validate the core logic of SurveyJS, including data models, expressions, validators, survey flow, and conditional logic. These tests are executed by Karma and Jest and operate independently of any UI rendering. Core unit tests are located in the survey-core/tests and survey-creator-core/tests directories, defined in the karma.conf.js and jest.config.js configurations, respectively. Additional functional tests can be found in the functionalTests/ folder.

Integration and rendering tests are maintained in framework-specific directories, such as packages/survey-angular-ui/test or packages/survey-react-ui/test to confirm that SurveyJS components behave correctly within their respective environments. These tests cover interactions, data binding, and validation, ensuring seamless integration with React, Angular, Vue3, or vanilla JavaScript applications. They are executed via Karma (karma.conf.js configuration) using the npm test command.

Markup tests (tests/markup/ directory) generate the HTML output for each framework and compare it to stored baselines. This approach ensures consistent rendering across frameworks and preserves accessibility attributes, preventing unintended differences in the visual or functional presentation.

End-to-End (E2E) tests reside under e2e/ directories and simulate full browser workflows, including typical user interactions and edge cases. Modern E2E testing is performed using Playwright (playwright.config.ts), while legacy scenarios utilize TestCafe configurations.

Visual regression tests (visualRegressionTests/, visualRegressionTests-V2/, screenshotTests/) detect unintended UI changes by comparing screenshots or DOM snapshots against established baselines.

Accessibility tests (accessibilityTests/) verify compliance with a11y rules across widgets, tabs, and survey flows. This ensures that our Form Library and Survey Creator components are usable by individuals with varying abilities.

All tests are enforced through CI/CD pipelines in Azure DevOps and GitHub Actions. A release cannot proceed unless all tests pass successfully, and results are logged for traceability. This structured approach provides assurance that each release meets SurveyJS standards for quality, consistency, and accessibility. These pipelines are defined in files such as azure-pipelines.yml for general builds, devops-pull-requests.yml for pull request validation, devops-visual-regression-tests.yml for UI regression checks, and devops-accessibility-tests.yml for accessibility validation.

Releases are versioned according to Semantic Versioning (SemVer):

• MAJOR: Incompatible API changes
• MINOR: Backward-compatible functionality additions
• PATCH: Backward-compatible bug fixes

Prior to release, all changes must pass CI/CD validation and peer review. Release candidates are tagged and tested in staging environments to validate functionality across all supported frameworks.

Releases are coordinated by designated maintainers, and only authorized personnel can publish official releases to npm.

To ensure transparency for users, detailed Release Notes accompany every version, documenting new features, enhancements, bug fixes, and known issues.

Validated releases are distributed via npm packages. Release candidates are staged and validated before public deployment. Automated CI/CD pipelines, such as release-azure-pipeline.yml ensure deployments are consistent, repeatable, and traceable. This minimizes the risk of errors during production rollout.

SurveyJS maintains ongoing support for all products through active monitoring of GitHub issues, Help Desk and community feedback channels, such as StackOverflow. Critical and high-priority issues are addressed promptly via weekly patch releases. Long-term supported versions receive backported fixes and security patches as needed. Users and contributors can report issues, request features, or seek support through GitHub or official support channels.

Development is conducted via GitHub repositories for each product. Features and bug fixes are tracked via issues and implemented via pull requests, which must pass peer review and a comprehensive Azure Pipeline. This pipeline enforces linting, build validation, functional, end-to-end, visual regression, and accessibility testing before merge. The architecture cleanly separates core logic (survey-core and survey-creator-core) from UI rendering, allowing consistent reuse across frameworks. Release artifacts are published to npm and GitHub via automated pipelines.