Software Development Lifecycle

1. Purpose and Objective

The Software Development Life Cycle (SDLC) outlines the typical process used by Izymes Pty Ltd to plan, develop, test, deliver, and maintain its software products.

The aim is to continuously promote quality, security, traceability, and improvement throughout all development activities related to these products.

Scope

This document applies to all software products developed, maintained, or supported internally by Izymes Pty Ltd – regardless of whether they are provided as cloud-based (Forge) or on-premises (Data Center) solutions.

2. Core Principles

Our development process is based on agile methods and combines them with a DevSecOps-oriented approach, aiming to create a close alignment between development, operations, support, and quality assurance.

We place great importance on short communication paths, high transparency, and automated processes to ensure efficient and reliable work.

Agile Approach

Our development approach is generally inspired by agile methodologies and follows an incremental process. Requirements are recorded and prioritized as issues in Jira. Each product increment is intended to conclude with a functional intermediate version that can be tested and reviewed. This approach enables quick adjustments based on customer feedback or new insights and supports continuous improvement.

Regular retrospectives help us to continuously improve both our working methods and the quality of our products.

DevSecOps Mindset

We strive for a high level of automation across the entire toolchain – from build, code security and quality assurance and test processes to deployment and documentation.

The goal is to ensure stable releases while minimizing the effort required for manual tasks. Development, testing, deployment, and operations (only if Izymes Pty Ltd is the operator) are viewed as a shared responsibility.

Security and Quality Focus

Security and quality are considered throughout all phases of the software life cycle whenever possible.

The intention is to evaluate security-related aspects early in the planning stage (“Security by Design”).
Tools for code analysis help ensure code quality, readability, and maintainability.
Tools for identifying security vulnerabilities support the early detection and remediation of potential risks.
Changes are ideally aligned with standardized processes to promote high quality and traceability.

Compliance Focus

Our SDLC is designed to support internal policies as well as contractual and regulatory obligations by ensuring that changes and decisions are transparent, traceable, and verifiable.

Digitally signed approvals: All code reviews and pull request approvals use digital signatures uniquely linked to the approving user, providing non-repudiation and tamper-evidence.
Mandatory reviewers for pull requests: Behavior-changing or security-relevant changes must be reviewed and approved by mandatory reviewers before merge, enforcing four-eyes and segregation of duties.
Policy-enforced merge checks: Branch protection and merge checks block merges unless required reviews, signatures, and automated checks (tests, quality and security scans) have passed.
Traceable approvals and configuration changes: Approvals and changes to CI/CD pipelines and tool configurations (e.g., quality gates, security scanners, access rules) are fully logged with who, when, what changed, and linked approvals.
Audit-ready evidence: Digital signatures, mandatory reviewers, and detailed audit logs produce exportable evidence for reviews and audits, demonstrating that processes were followed.

Collaboration and Transparency

Our collaboration is characterized by openness, trust, and mutual support. We aim to document key work results – such as code, documentation, test reports, and decisions – in version control or documentation systems as transparently as possible.

This approach is intended to help ensure that all stakeholders remain informed about the current project status and context, and that changes can be traced in a clear and transparent manner.

Customer Collaboration

We aim to actively involve our customers in the development process. Feedback received through service management, email, or communication in customer projects is incorporated into our planning and helps us to further develop our products in a practical and focused manner.

In addition, Izymes uses public roadmaps and public feature request collection and voting to ensure that customer needs directly influence internal decisions and planning:

Public roadmaps: We maintain product roadmaps visible to customers and partners to provide transparency about planned features, priorities, and timelines.
Public feature requests: Customers can submit new feature ideas in a central, public channel (e.g., a public Jira Service Management project or feedback portal). Each request is tracked, triaged, and linked to internal Jira issues where appropriate.
Voting and feedback signals: Customers can vote and comment on requests; vote counts and qualitative input are key signals used in prioritization.
Influence on internal planning: During backlog refinement and release planning, product owners and the team review highly requested, high-impact public requests alongside feasibility, security/compliance, and strategy to decide what enters product and release backlogs.
Traceability from idea to delivery: Where possible, public requests are linked to internal Jira issues, pull requests, and release notes to provide end-to-end traceability and close the feedback loop.

3. Tools and Systems

Our tool landscape is designed to support efficiency, transparency, and traceability, helping us to cover the entire software development life cycle.

Project Management	Jira	Managing requirements, tasks, and workflows
Documentation	Confluence	Technical documentation, architecture, process descriptions, and product documentation
Support & Incident Management	Jira Service Management	Ticketing for support requests, malfunctions, and general communication
Version Control	Git	Managing source code, versioning, branching, merging, and ensuring traceability of changes
Code Management	Bitbucket	Managing repositories, pull requests, permissions, code reviews, and CI/CD integrations
Code Quality & Security	Semgrep and FindSecBugs, Linters for relevant technologies, Snyk / OWASP Tools + several linter depending on the technology used	Monitoring code quality, detecting code smells, ensuring compliance with standards, and analyzing dependencies and potential security vulnerabilities
Testing	Several test frameworks depending on the technology used	Performing unit, integration, and end-to-end tests, UI-tests
CI/CD	Bitbucket Cloud / Maven / Nodejs tools	Managing build, test, and deployment processes to support continuous delivery
Artifact Management	Nexus / npmjs	Storing, versioning, and managing build artifacts such as libraries and packages
Integrated Development Environment	VS Code and IntelliJ IDEA	Local development and debugging environments for various programming languages and frameworks. The goal is to make all quality-related information available directly within the development environment.
Responsible use of AI	Atlassian RovoDev	Low-impact assistant for code implementation and bug fixing (snippets, refactors, hypotheses); final design, efficiency, security, and code reviews remain governed by qualified human engineers.

4. Phases of the Software Development Life Cycle

This chapter outlines the phases of the development process — from the initial idea through implementation to maintenance. Each phase contributes to ensuring quality, stability, and security and is defined by clear responsibilities and workflows.

Enlarges the table by opening it in a full screen dialogOpen

Planning	Jira, Confluence	Capturing, evaluating, and prioritizing requirements (functionality, security, quality, and objectives)
Design	Confluence, Markdown, http://draw.io	Technical and conceptual design of the software, including security and interface design
Development	VS Code, IntelliJ IDEA, Git, Bitbucket	Implementation of the defined requirements in source code
Quality Assurance	Bitbucket, Semgrep, Snyk, OWASP, various linters, Test suites	Verifying that the software meets the defined requirements (functional, non functional, technical and security-related)
Deployment	Bitbucket, Nexus, Atlassian Marketplace	Delivering software to end users or production systems in a controlled manner
Maintenance	Jira Service Management and all other tools	Communication, continuous maintenance, bug fixing, further development, and optimization

4.1 Planning

This phase lays the foundation for each project by collecting, evaluating, and prioritizing requirements.

We maintain a central product backlog that is continuously updated with new ideas, requirements, improvements, and known bugs. The product backlog is informed by our internal product development roadmap, external/public feature requests and voting signals, and non‑critical bug fixes identified through support and maintenance.
From this product backlog, the goal is to create a release backlog that defines the content of a planned version or release.
A planned release may include new features, optimizations, and non-critical or minor bug fixes. (Hotfixes are handled separately; see the Maintenance section.)
The release backlog results from team-based prioritization according to effort, benefit, and risk.

The release backlog serves as the starting point for the subsequent phases of the development process.

4.2 Design

In this phase, the technical foundation of the software is established. The goal is to create a robust, secure, and scalable architecture that allows for future extensions and enhancements.

Key architectural, interface, and design decisions can be documented in Confluence wherever possible.
Security aspects (e.g., OWASP Top 10) are ideally considered already at this stage of the development process.

4.3 Development

This phase covers the actual implementation of the requirements and forms the core of the entire software development process. The goal is to create stable, maintainable, and secure software that meets the defined requirements and can be operated reliably over the long term. We aim to keep all development activities transparent and traceable, using version control and working closely with established workflows, testing, and quality assurance processes.

We use Git for version control and follow the GitFlow-Based Development workflow.
All behavior-changing code modifications are carried out according to the principles of Feature-Driven Development (FDD).
For cloud products, separate staging and production branches may be used to enable controlled testing and deployment.
All code changes must be submitted through pull requests, no direct push permissions to protected branches such as main, release/* etc.
Whenever possible, each pull request should be reviewed by at least one additional team member.
We use SAST tools and linters to enforce consistent code quality, code security and style during implementation.
Unit tests are written for every code change to verify correctness and prevent regressions.
We enforce running integrated vulnerability checks for dependencies in both local development environments and CI/CD pipelines.
Jira tickets are linked to commits, branches, and pull requests to ensure complete traceability and auditabilility throughout the process.

4.4 Quality Assurance

Our quality assurance aims to ensure that each change meets the defined requirements and does not cause unintended regression and side effects. The primary goal is to detect issues as early as possible and maintain a high level of software quality and stability.

Quality assurance usually begins in the early stages of development. The aim of tests and code analyses is to detect potential issues early on and increase confidence in the reliability of each change.

Testing

We distinguish the following types of tests as part of our quality assurance process:

Unit Tests: Verification of individual functions or modules to ensure correct operation.
Integration Tests: Ensuring that multiple components interact correctly with one another.
System Tests: Testing the overall system under realistic conditions (e.g., using test data or simulated interfaces).
UI Tests: Automated verification of user interface behavior and interaction, ensuring that workflows and visual components function as expected across supported environments.

In addition, we place particular focus on the following aspects:

Regression: Automated repetition of tests to ensure that new changes do not affect existing functionality.
Code Coverage: As part of automated testing, we aim to continuously measure code coverage to assess the level of test completeness.

Code Analysis

We distinguish the following types of code analyses as part of our quality assurance process:

Static Application Security Testing (SAST): Analysis of source code to identify potential security risks.
Software Composition Analysis (SCA): Review of external dependencies and open-source components for known vulnerabilities.

Automation

Tests and code analyses are largely automated and integrated into the CI/CD pipeline. The goal is for each code commit or pull request to automatically trigger relevant tests. This helps ensure that faulty or insecure changes are not introduced into the main development line. If issues are detected, builds may be stopped and the responsible teams notified. Test results are documented in the respective systems (e.g., CI systems).

If any automated testing step fails or code analysis reports blocking issues, the release/deployment is halted until the issues are resolved and re-validated.

We aim to minimize manual testing to ensure consistency, repeatability, and efficiency. Where appropriate, additional manual tests can be planned and documented to complement the automated coverage.

PEN Testing and Bug Bounty Programs

To complement internal security measures, Izymes Pty Ltd also actively participate in bug bounty programs. All public products and apps are published targets. The goal is to identify potential vulnerabilities early through independent expertise and to continuously enhance product security. Any identified issues are reviewed, prioritized, and handled through the standard vulnerability, development and maintenance process.

4.5 Deployment

Deployment describes the planned process by which a tested and approved software version can be delivered to a target environment (e.g., staging, production, or npmjs, or Marketplace). The goal is to ensure that the software is deployed in a controlled, reproducible, and traceable manner — regardless of whether it is operated as a cloud service or an on-premises solution.

Deployment Strategy

We follow a Continuous Delivery approach. This means that after every successful build and all passing tests, each version is potentially ready for production use.

Deployments for cloud products are executed automatically as part of the CI/CD pipeline, while deployments to Marketplace are carried out manually by authorized team members to provide a final level of control and validation.

Deployment Types

Cloud Products:Deployments to staging and production environments are typically carried out through automated CI/CD pipelines within a defined cloud environment (e.g., Atlassian Forge or Atlassian Connect Express). Separate staging environments are used to validate changes in a controlled manner before they go live to a production environment.
On-Premise Products:Deployment is handled via an artifact management system or an official marketplace (e.g., Atlassian Marketplace). Installable packages or containers are provided, which can be installed manually by our team or by the customer. This approach allows flexibility across different customer environments while supporting internal quality and security standards.

Traceability

Each deployment is versioned and assigned a specific release number. Version details and changes are documented so that it can be traced at any time:

which version was deployed, and
which changes were included.

Release Documentation

After a successful deployment, a release entry is typically created in the documentation.

This entry usually includes:

the version number,
a description of the implemented changes, and
information about any specific notes or limitations.

4.6 Maintenance

After deployment, the active phase of maintaining and supporting the software begins. The goal is to ensure stable and secure operation, respond efficiently to reported issues, and support continuous improvement through systematic analysis.

Error Handling and Prioritization

All reported or identified issues are, where possible, recorded in Jira as issues of type Bug and assigned a severity level. The severity level depends on the impact on functionality or security.

Prioritization generally follows this principle:

Critical Issues (Hotfix):Issues that are security-relevant or significantly affect productive operation are addressed immediately and resolved in a dedicated hotfix release. Such a release contains only the necessary corrections to quickly restore functionality or security. The hotfix is typically prioritized for implementation, tested, documented, and released after successful validation.
Non-Critical Issues:Issues without security- or business-critical impact are prioritized and included in the next planned release. These bugs follow the standard development, testing, and release process and are scheduled in the product backlog of a future release to ensure stable and traceable integration into the product.

Product Care

Regular maintenance activities help ensure that the software remains stable, secure, and up to date over the long term.

Typical activities include:

updating libraries, frameworks, and dependencies,
addressing technical debt,
improving performance and compatibility, and
adapting to new system environments or customer requirements.

Where appropriate, the results of these activities are documented and considered during future release planning.

Customers and Reporting Channels

Customers are essential to our maintenance activities and form a central part of our quality and continuous improvement process. To report issues, suggest improvements, or share security-related information, the Jira Service Management system is available as the primary communication and tracking channel. Additionally a public product roadmap with feedback and voting options serves as an extension to Jira Service Management to inform product planning.

End of Maintenance

It is planned to align our products with the Atlassian Long-Term Support (LTS) versions. For on-premises products, the goal is to maintain compatibility with the two most recent LTS versions of the corresponding Atlassian host product (e.g., Bitbucket). In the cloud, the latest version is typically maintained and continuously updated.