-
Notifications
You must be signed in to change notification settings - Fork 35
Home
dbradham edited this page Oct 6, 2024
·
32 revisions
This repository contains the code for all of the front end Dev Launchers applications. This includes:
- All routing and links are handled with NextJS
- All projects export their relevant components from the
/pagesand/componentsdirectories - The components within the
/pagesdirectories include the app root, and page wrappers with minimal code - The app root should import the project theme and user data context from the shared components library
- The components within the
/componentsdirectory should be broken into two categories which are represented as subdirectories: 1) modules and 2) common- Components in
/components/modulesare "one-offs", such as a section of a page that contains stateful data specific to that page - Components in
/components/commonare used on multiple pages or referenced from multiple places within the same page
- Components in
To view the existing portfolio of components, click here!
You will need to import the component like so:
import { atoms } from '@devlaunchers/components/src/components';
Then you could access different atoms like so:
<atoms.Box>
{/* inner content for the box would go here */}
</atoms.Box>
- All contributions to the repository are based on development tickets created by each team's product experts
- Developers are assigned or pick up these tasks voluntarily to achieve a specific result for the organization by contributing to this repository
- All pull requests should be merged after receiving 1 approval from another stakeholder who understands the entire scope of the change being made
A comprehensive guide may be found here
- There are two branches shared between all teams:
master(staging) andrelease-
masterwill deploy to a universal staging environment - https://staging.devlaunchers.org -
releasewill deploy to production - https://devlaunchers.org
-
- All tech leads should keep their own development branch and rebase off of the
master/staging branch often- The branch should be named like so:
development/<teamName>
- The branch should be named like so:
- For individual contributions to the platform:
- Every developer should create a new branch based off their team's development branch
- The branch should be named like so:
<teamName>/<nameForTask>
- When the individual contribution has been implemented and tested locally, the developer should make a pull request to their team's development branch
- Before merging, at least one "code owner" should approve the request
- After each sprint All tech leads should merge
development/<teamName>tostaging/<teamName>- This will trigger a deployment to a staging environment made specifically to the team
- contents of
staging/<teamName>will be deployed to https://teamName.devlaunchers.org - If your team wants to do A/B testing they can merge to
staging/<teamName>1for the A test andstaging/<teamName>2for the B one, changes will be deployed to https://teamName1.devlaunchers.org and https://teamName2.devlaunchers.org accordingly!
