Hoppa till huvudinnehåll
Alla samlingarSystemstatus & Driftsäkerhet
Software Development Life Cycle
Software Development Life Cycle

Change, review, release, deploy

Uppdaterad för mer än 3 veckor sedan
  1. Introduction

This policy outlines the structured approach to software development at Howwe Technologies AB. By adhering to a disciplined Software Development Life Cycle (SDLC), we ensure that system reliability, security, and scalability are maintained throughout development, review, release, and deployment processes.

2. Development Lifecycle Overview

2.1. Code Isolation

  • A new branch is created from the master branch for each feature or task.

  • Branch naming convention: {first-name}/{feature-name} (e.g., jane/some-feature).

  • Developers are responsible for ensuring that isolated branches reflect specific, well-defined tasks.

2.2. Writing Code

  • Clarity Before Action: Developers must clarify any ambiguity in task requirements with their manager or peers.

  • Early Communication: Proactive discussions about potential impacts on infrastructure, security, network, communication, or API design are encouraged.

  • Reference Materials:

    • Consult internal documentation and the company wiki.

    • Engage team members for feedback and knowledge-sharing.

Key Principles:

  1. Plan thoroughly before implementing changes.

  2. Reflect on broader implications of code changes.

  3. Collaborate and communicate frequently.

2.3. Pull/Merge Requests (PRs)

  • Developers must create a pull/merge request (PR) on the version control platform (GitHub).

  • PR descriptions should include:

    • A concise summary of the changes.

    • A link to the associated Notion task (if applicable).

  • Large or impactful changes should be broken into smaller, manageable PRs for easier review and testing.

2.4. Code Review Process

  • Submitting for Review:

    • Share the PR with appropriate reviewers via Slack in team-specific channels (e.g., team-frontend, team-backend).

    • Notify relevant colleagues for input, especially for changes affecting infrastructure, security, or API design.

  • Review Objectives:

    • Validate adherence to coding standards and best practices.

    • Ensure changes are aligned with task requirements.

    • Assess potential impacts on infrastructure, network, and system performance.

  • Post-Review Changes:

    • Incorporate reviewer feedback promptly.

    • Communicate with the reviewer to confirm updates and resolve any outstanding concerns.

3. Release and Deployment

3.1. Deployment Readiness

Before deployment, ensure that:

  • Automated tests (unit, integration, end-to-end) have passed.

  • Manual QA validation is completed in the QA Environment.

  • New features or updates are tested in the Demo Environment to simulate production conditions.

3.2. Deployment Process

Deployment follows clear, standardized instructions documented in the company wiki.

Key steps include:

  1. Deploy code to the production environment via automated CI/CD pipelines managed by Google Cloud Build and Kubernetes.

  2. Monitor deployment status and system health in real time using Google Cloud Monitoring.

  3. Verify service functionality through automated post-deployment tests and manual checks.

3.3. Rollback Procedures

  • If issues arise during deployment, use Kubernetes rollback capabilities to restore the last stable version.

  • Log all rollback actions for future reference and post-deployment analysis.

4. Documentation and Continuous Improvement

4.1. Documentation Requirements

  • PRs must include relevant updates to documentation if code changes affect:

    • APIs or external integrations.

    • Infrastructure or deployment processes.

    • End-user features.

4.2. Post-Deployment Review

  • Conduct a retrospective after significant releases to identify lessons learned.

  • Log key findings in the company’s knowledge base for future reference.

4.3. Continuous Learning

  • Developers are encouraged to participate in regular code review workshops and system architecture discussions.

  • Best practices and lessons from past projects are integrated into ongoing training sessions.

5. Tools and Platforms

  • Version Control: GitHub for branch management, code reviews, and pull requests.

  • Continuous Integration/Continuous Deployment (CI/CD): Google Cloud Build and Kubernetes for automated testing and deployment.

  • Monitoring and Exception Tracking: Google Cloud Monitoring and Sentry for real-time error tracking and performance analysis.

  • Documentation: Company wiki and internal knowledge base for deployment and SDLC workflows.

Fick du svar på din fråga?