Skip to main content

Phase 3: Development

This phase marks the execution of the design, where the architectural plans are turned into tangible software through coding and infrastructure build-out. In the Osborn project, this is an iterative process focused on writing secure, high-quality code within the established project structure (Django for backend, React for frontend).

Key Activities​

1. Code Implementation​

  • Execution of Design: The development team begins coding according to the approved architecture.
  • Code Branching: Following the Development Workflow, a new branch must be created exclusively from the Jira task. The branch name will follow the format OPD-[number]-[description].
  • Code Repository: All code is maintained and version-controlled in the project's Bitbucket repository.
  • Issue Log: An issue log is maintained in the Jira ticket to track problems and bugs encountered during development.

2. Infrastructure as Code (IaC)​

  • Automated Environments: Development, test, and staging environments are built and deployed using IaC services. While the Omnicom standard is TerraForm Cloud for Business, Osborn may also leverage AWS-native tools like CloudFormation or CDK.
  • API Gateway: For custom APIs developed in the Django backend, an API Gateway is used to expose them securely.

3. Early and Continuous Testing​

  • Unit and Integration Testing: Developers are responsible for writing tests for their code.
    • Backend: Follows the testing guidelines for Django, using tools like pytest-django.
    • Frontend: Uses tools like Jest and React Testing Library for testing React components.
  • Peer Code Reviews: All code must be peer-reviewed via a Pull Request in Bitbucket before being merged into the develop branch.
  • Vulnerability Testing: The Osborn CI/CD pipeline in Bitbucket automatically runs a mix of security vulnerability testing tools to identify issues early. This includes:
    • Static Application Security Testing (SAST)
    • Software Composition Analysis (SCA) to check for vulnerabilities in open-source libraries.
    • Interactive Application Security Testing (IAST)
  • Serverless Testing: For any cloud-native serverless solutions (e.g., the Email Delivery Service), a specific Serverless Vulnerability Testing tool is used.

Control Point​

  • A formal Control Point, which includes the successful completion of the Pull Request process (code reviews, passing CI/CD checks), must be passed before the code is merged and promoted to the Testing phase.
  • All quality, security, and IT service requests associated with the Jira task must be resolved.