Development at Dev Launchers

The Development Process at DevLaunchers outlines the standardized workflow, tools, and best practices developers follow to build, test, and deploy features or fixes on the platform. This structured approach ensures consistency, high-quality code, and efficient collaboration within the team. The process emphasizes key aspects such as local development, version control, automated testing, and code reviews, all designed to streamline development and maintain platform reliability.

Development Process Diagram

1. Local Development and Testing

• Setting Up the Environment: Developers start by configuring their local environment. This includes setting up Strapi, running necessary dependencies, and initializing the local database. Tools such as Node.js, Docker, and npm commands are essential for the setup process.

• Feature Development: Each developer works on a specific feature, bug fix, or enhancement by writing code locally. This is done in alignment with the project’s requirements and acceptance criteria as defined in tickets or documentation.

• Testing Locally: Code is tested locally to ensure it works as intended and does not introduce regressions. Developers leverage tools such as Postman (for API testing), Strapi's built-in testing environment, or mock data to simulate real-world scenarios.

• Branching: Once local testing is complete, developers create a new branch in the GitHub repository to isolate their changes. The branch name should follow a predefined naming convention, such as: username/<feature-name>

Branches in Repository

2. Creating a Pull Request (PR)

• After completing their work in the branch, developers push their code to the remote GitHub repository.

• They then create a Pull Request (PR).

  • The PR title and description should include relevant details, such as the purpose of the changes, the issue or feature being addressed, and any dependencies or testing instructions.

  • The PR serves as the primary way for the team to collaborate on and discuss proposed changes before merging them into the main codebase.

3. Automated Testing

• GitHub Actions Integration: Submitting a PR triggers automated testing workflows via GitHub Actions. These workflows run predefined test suites to validate the code.

• Test Results: If the code fails any of the automated tests, the PR will be marked as failing, and the developer must fix the issues before proceeding. Only PRs with passing tests are eligible for review.

Github Action Tests

4. Code Review

• Collaborative Review: Once the automated tests pass, the PR is reviewed by both peers or team leads.

  • Reviewers examine the code for:

    • Adherence to coding standards.

    • Code readability, maintainability, and performance.

    • Proper handling of edge cases and errors.

    • Security concerns and best practices.

• Feedback and Iteration: Reviewers may provide feedback or request changes. The developer revises the code accordingly and updates the PR until all comments are resolved.

5. Merging Approved Code

• Approval and Merge: Once the code passes both automated tests and manual code reviews, it is approved for merging.

  • Developers merge the branch into the main branch (staging branch).

• Deployment to Staging: The merged code is automatically deployed to the staging environment. This allows the team to perform final testing and validation before deploying it to production in the next release.

6. Deployment to Production

• Once the code has been validated in staging, it can be deployed to the production environment. This deployment process require manual triggers by pushing the code to the release branch (production branch).

Development Environment and SVM Setup

1. Version Control

• DevLaunchers uses Git for version control, hosted on GitHub.

• Developers follow a branching strategy to manage feature development, bug fixes, and releases.

2. Environment Types

The development pipeline includes multiple environments to ensure code quality and stability:

• Local Environment: Where developers write and test code on their machines.

• Staging Environment: A replica of production used for final testing.

• Production Environment: The live application used by end-users.

3. Source Version Manager (SVM)

• GitHub is the primary SVM used to manage the source code repository.

• Developers interact with the repository using Git commands and PR workflows.