Software Development Life Cycle

1. Purpose

The Software Development Life Cycle describes how DevOpsSystems plans, develops, tests, releases, and maintains its software products.

The purpose of this document is to provide transparency about the development process and to support quality, security, traceability, maintainability, and continuous improvement.

2. Scope

This SDLC applies to software products developed, maintained, or supported by DevOpsSystems GmbH, including:

• Atlassian Forge apps,

• Atlassian Data Center apps,

• supporting libraries and components,

• release and build processes,

• product documentation where relevant.

The exact implementation of individual controls may vary depending on product architecture, technology stack, deployment model, customer requirements, and product maturity.

3. Core Principles

DevOpsSystems follows a development approach based on the following principles:

• security by design,

• quality by design,

• traceability of changes,

• automation where practical,

• least privilege,

• controlled release processes,

• customer-oriented improvement,

• maintainability,

• continuous improvement.

4. Development Approach

DevOpsSystems uses an agile and incremental development approach.

Requirements, bugs, improvements, and maintenance tasks are captured and prioritized using Jira. Product increments are planned, implemented, tested, reviewed, and released according to product needs and customer impact.

Customer feedback from support requests, customer projects, security reports, and operational experience may be incorporated into planning.

5. Team and Responsibility

DevOpsSystems operates with a small team structure, currently as a single-developer setup. Roles may be combined or performed by the same person depending on team size and product context.

Typical responsibilities include:

Where one person performs multiple roles, automated quality gates, documented procedures, and structured pull request workflows are used to maintain quality and traceability in place of a separate human reviewer.

6. Tools and Systems

The development process uses the following tools and systems.

7. SDLC Phases

The DevOpsSystems SDLC consists of the following phases:

1. Planning

2. Design

3. Development

4. Quality Assurance

5. Deployment

6. Maintenance

7. Continuous Improvement

8. Planning

During planning, requirements, bugs, improvements, security tasks, and technical maintenance items are collected and prioritized.

Planning activities may include:

• capturing customer requirements,

• reviewing support feedback,

• assessing security and quality requirements,

• prioritizing product backlog items,

• defining release scope,

• evaluating risk and effort,

• identifying dependencies,

• planning maintenance activities.

Planning information is usually tracked in Jira.

9. Design

During design, technical and functional decisions are prepared before or during implementation.

Design activities may include:

• architecture decisions,

• interface design,

• permission and scope design,

• data flow review,

• security considerations,

• configuration design,

• compatibility assessment,

• documentation of important decisions.

Security considerations such as least privilege, input validation, authentication, authorization, and secure data handling are considered where applicable.

Design decisions may be documented in Confluence, Markdown, source repositories, Jira issues, or architecture notes.

10. Development

Development activities are performed using Git-based version control.

Development practices may include:

• working from Jira issues or documented requirements,

• linking commits, branches, and pull requests to Jira issues where practical,

• using pull requests for behavior-changing code modifications,

• reviewing code changes before merge where feasible,

• using trunk-based development or a controlled branch strategy depending on product needs,

• using staging and production branches for cloud products where appropriate,

• applying coding standards and linters,

• writing tests for relevant changes,

• checking dependency and security findings,

• documenting relevant implementation details.

DevOpsSystems operates as a single-developer setup. A separate human reviewer is not available for every pull request. In this context, the pull request workflow serves as the primary quality gate: all pull requests are subject to automated checks enforced by the CI/CD pipeline before merge is permitted. These automated gates include static application security testing (CodeQL), software composition analysis, secret detection, code quality checks, and automated tests. Pull requests that do not pass these checks cannot be merged. Self-review, focused testing, and retrospective review complement these automated controls to reduce the risk of undetected issues reaching production.

11. Quality Assurance

Quality assurance is performed to verify that changes meet functional, technical, quality, and security expectations.

Quality assurance may include:

• unit tests,

• integration tests,

• system tests,

• UI tests,

• regression tests,

• manual verification,

• code review,

• static code analysis,

• dependency scanning,

• security checks,

• compatibility checks,

• documentation review.

The exact QA scope depends on the type of change, product architecture, risk, and release context.

12. Testing

Testing aims to detect defects early and reduce the risk of regressions.

Typical test types include:

DevOpsSystems aims to automate tests where practical and maintain test coverage appropriate to product risk and complexity.

13. Code Analysis and Security Checks

Code and security analysis may include:

• Static Application Security Testing (SAST),

• Software Composition Analysis (SCA),

• dependency vulnerability scanning,

• secret detection,

• code quality checks,

• linting,

• security-focused code review,

• Dynamic Application Security Testing (DAST) — planned for selected products and scenarios.

14. Automation

Automated checks are integrated into development and CI/CD workflows where practical.

Automation may include:

• build validation,

• unit tests,

• integration tests,

• linting,

• code quality checks,

• dependency checks,

• secret scanning,

• packaging,

• release preparation,

• deployment steps for cloud apps.

Failed checks are reviewed and resolved according to risk and relevance before release.

15. Deployment

Deployment is performed in a controlled and traceable manner.

Forge and Cloud Apps

Forge and cloud app deployments may use Atlassian Forge environments, staging environments, production environments, and automated deployment scripts.

Changes are validated before production deployment where practical.

Data Center Apps

Data Center app releases are typically packaged and published through an artifact repository or Atlassian Marketplace.

Customers are responsible for installing or upgrading Data Center apps in their own environments.

16. Release Documentation

Releases are documented where appropriate.

Release information may include:

• version number,

• release date,

• changes included,

• bug fixes,

• security-relevant updates,

• compatibility information,

• upgrade notes,

• known limitations.

Release documentation helps customers understand changes and supports traceability.

17. Maintenance

After release, products are maintained through support, monitoring of customer feedback, vulnerability management, dependency updates, bug fixes, and planned improvements.

Maintenance activities may include:

• bug analysis,

• hotfix planning,

• dependency updates,

• security fixes,

• compatibility updates,

• performance improvements,

• documentation updates,

• technical debt reduction.

18. Bug Fixing and Hotfixes

Issues are recorded, assessed, prioritized, and tracked.

Critical or security-relevant issues may be handled as hotfixes.

Non-critical issues are prioritized and planned into future releases according to business value, risk, customer impact, and available capacity.

19. Vulnerability Handling

Security vulnerabilities are handled according to the Vulnerability Management Program.

The SDLC supports vulnerability handling through:

• secure development practices,

• code review,

• automated checks,

• dependency scanning,

• security testing,

• traceable remediation,

• controlled release processes.

20. End of Maintenance and Compatibility

For Data Center products, DevOpsSystems supports the two most recent Atlassian Long-Term Support (LTS) versions of the relevant Atlassian host product. When Atlassian releases a new LTS version, DevOpsSystems aims to validate and publish compatibility with that version in a timely manner. Versions older than the two most recent LTS releases are not covered by active compatibility maintenance.

For cloud products built on Atlassian Forge, versioned compatibility maintenance does not apply in the same way as for Data Center products. Atlassian Cloud updates continuously and automatically; customers do not operate a specific host product version. DevOpsSystems maintains the current version of each Forge app, compatible with the current Atlassian Forge platform and APIs. Where Atlassian announces deprecations or breaking changes to Forge APIs or platform behavior, DevOpsSystems aims to adapt affected apps within the transition period communicated by Atlassian.

21. Documentation

Documentation is maintained as part of the product lifecycle.

Documentation may include:

• user documentation,

• administrator documentation,

• release notes,

• configuration examples,

• troubleshooting information,

• security and privacy documentation,

• internal process documentation.

22. Continuous Improvement

DevOpsSystems reviews development, support, release, and security outcomes to identify improvement opportunities.

Continuous improvement may be based on:

• retrospectives,

• customer feedback,

• support trends,

• vulnerability findings,

• incident reviews,

• tool results,

• code quality findings,

• release experience.

23. Related Documentation

• Security Policy

• Vulnerability Management Program (VMP)

• Service Level Agreement (SLA)

• App Privacy Policy (Forge & Data Center)

• Help Portal Privacy Policy

• End-User License Agreement (EULA)

24. Review and Updates

This SDLC document is reviewed periodically and may be updated to reflect changes in development practices, tools, technologies, products, security requirements, or business operations.

Last updated: 2026-06-01