Development Guidelines for the Alliance Business Suite

Version: 1.1

Date: 28/08/2023

Contributing to the Alliance Business Suite is a collaborative endeavor, and we appreciate your interest. This guide outlines the best practices and procedures to follow when developing features or fixing bugs for the platform.

Table of Contents

  1. Introduction
  2. Development Environment
  3. Branching Strategy
  4. Coding Standards
  5. Code Reviews
  6. Testing
  7. Deployment
  8. Documentation

Introduction

This guide serves as a comprehensive overview of the expectations and requirements for developers contributing to the Alliance Business Suite. Adherence to these guidelines ensures that our codebase remains maintainable, robust, and easy to understand.

Development Environment

Refer to the Dev Env Setup guide to set up your development environment. This guide outlines steps to RDP into the Corporate Server, clone the ABS repository via SSH, install VS Code, and configure posh-git and oh-my-posh.

Branching Strategy

We follow a modified Git Flow branching strategy that includes personal branches:

  1. main Branch: Contains the stable release.
  2. develop Branch: Is for day-to-day development.
  3. feature/<feature-name> Branches: For new features.
  4. bugfix/<bug-name> Branches: For bug fixes.
  5. <username>/personal Branches: Personal branches named after the developer for experimenting or long-term work that will eventually be merged back into develop.

Personal Branches

  1. Naming: These branches should be named with your username, followed by /personal. For example, if your username is daniel, then your personal branch should be named daniel/personal.

  2. Usage: Use your personal branch for prototyping, experimental features, or work-in-progress tasks that aren't ready to be shared with the team.

  3. Merging: Code from personal branches should eventually be reviewed and merged into develop or appropriate feature branches. They should not be merged directly into master.

  4. Updates: Keep your personal branch up-to-date with the develop branch to avoid merge conflicts.

By adhering to this branching strategy, including the use of personal branches, we aim to keep our workflow organized and our codebase clean and manageable.

Coding Standards

  1. Language Standards: Use consistent casing, indentation, and code organization.
  2. Comments: Add meaningful comments that clarify code purpose and behavior.
  3. Commit Messages: Use descriptive commit messages that reflect the changes made.

Code Reviews

  1. Peer Reviews: All pull requests should be reviewed by at least one other developer.
  2. Automated Checks: Ensure that automated checks (tests, linters, etc.) pass before merging.
  3. Conflict Resolution: Resolve all merge conflicts locally before submitting a PR.

Testing

  1. Unit Tests: Write unit tests for all new features and bug fixes.
  2. Integration Tests: Ensure that your code works well with existing features.
  3. Regression Testing: Run existing tests to ensure new code doesn't break existing functionality.

Deployment

  1. Staging: Test all changes in the staging environment before deploying to production.
  2. Rollback Plans: Have a plan in place for rolling back code in case of errors.
  3. Monitoring: Monitor application logs and performance metrics after deployment.

Documentation

  1. Code Comments: Inline comments should be used sparingly and only when necessary to explain complex logic.
  2. Documentation: Update relevant documentation to reflect changes.
  3. Release Notes: Maintain a log of all changes made for each release.