mirror of
https://github.com/cse110-fa22-group29/cse110-fa22-group29.git
synced 2024-12-27 09:29:10 +00:00
Merge pull request #52 from cse110-fa22-group29/ci-architecture-dev
Add CI/CD ADRs and phase1 documentation
This commit is contained in:
commit
5884dd4449
BIN
admin/cipipeline/phase1.drawio.png
Normal file
BIN
admin/cipipeline/phase1.drawio.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 42 KiB |
36
admin/cipipeline/phase1.md
Normal file
36
admin/cipipeline/phase1.md
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
# CI/CD Phase 1
|
||||||
|
|
||||||
|
## Overall Pipeline Architecture
|
||||||
|
|
||||||
|
Rather than create one large pipeline with many steps which increases complexity, we decided to create many small independent pipelines which work in parallel to conduct code quality checking. Using this strategy, if any one pipeline has issues, we can still continue development without delay, and the quality of code is likely to remain high.
|
||||||
|
|
||||||
|
## Overview of Pipeline Features
|
||||||
|
|
||||||
|
We've identified 5 major features which we definitely want to implement in the CI/CD pipeline.
|
||||||
|
|
||||||
|
- Deployment
|
||||||
|
- Unit Testing
|
||||||
|
- Linting
|
||||||
|
- End To End Validation
|
||||||
|
- Manual Validation
|
||||||
|
|
||||||
|
We created this diagram to demonstrate our strategy of multiple simple pipelines.
|
||||||
|
|
||||||
|
![Pipeline Diagram](phase1.drawio.png)
|
||||||
|
|
||||||
|
## Finished Features and Implementation
|
||||||
|
|
||||||
|
So far the features listed below have been completed to some degree:
|
||||||
|
|
||||||
|
- Deployment
|
||||||
|
- Implemented: action triggered on any push to main, uses the github pages action to publish the app
|
||||||
|
- ToDo: Add minifications ste between trigger and github pages action
|
||||||
|
- Unit Testing
|
||||||
|
- Implemented: action triggers on any PR, uses mocha to perform unit testing on core components
|
||||||
|
- ToDo: trigger workflow only on certain PRs which relate to JS code
|
||||||
|
- Linting (JS)
|
||||||
|
- Implemented: ction triggers on any PR, uses eslint to perform style enforcement on all JS components
|
||||||
|
- ToDo: trigger workflow only on certain PRs which relate to JS code
|
||||||
|
|
||||||
|
|
||||||
|
## Planned Features and Timeline
|
0
admin/cipipeline/phase1.mp4
Normal file
0
admin/cipipeline/phase1.mp4
Normal file
19
specs/adrs/111222-cicd-multiple-pipelines.md
Normal file
19
specs/adrs/111222-cicd-multiple-pipelines.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
# Use multiple CI/CD pipelines in parallel
|
||||||
|
|
||||||
|
- Status: accept
|
||||||
|
- Deciders: Arthur Lu, Marc Reta
|
||||||
|
- Date: 11 / 12 / 22
|
||||||
|
|
||||||
|
## Decision Drivers
|
||||||
|
|
||||||
|
- Need to perform many different CI/CD tasks
|
||||||
|
- Need pipeline to be durable against any single failure
|
||||||
|
|
||||||
|
## Considered Options
|
||||||
|
|
||||||
|
- Single deep pipeline
|
||||||
|
- Multiple short pipelines in parallel
|
||||||
|
|
||||||
|
## Decision Outcone
|
||||||
|
|
||||||
|
Chosen Option: Multiple short pipelines in parallel as any one failure will not prevent code from being developed and deployed.
|
19
specs/adrs/111222-jslinting-eslint.md
Normal file
19
specs/adrs/111222-jslinting-eslint.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
# Use eslint for JS linting framework
|
||||||
|
|
||||||
|
- Status: accept
|
||||||
|
- Deciders: Arthur Lu, Marc Reta
|
||||||
|
- Date: 11 / 12 / 22
|
||||||
|
|
||||||
|
## Decision Drivers
|
||||||
|
|
||||||
|
- Need linting to work with multiple style standards
|
||||||
|
- Need linting to be fast and informative
|
||||||
|
|
||||||
|
## Considered Options
|
||||||
|
|
||||||
|
- JSLint
|
||||||
|
- eslint
|
||||||
|
|
||||||
|
## Decision Outcome
|
||||||
|
|
||||||
|
Chosen Option: eslint for its low configuration complexity.
|
19
specs/adrs/111222-jsunittest-mocha.md
Normal file
19
specs/adrs/111222-jsunittest-mocha.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
# Use mocha for JS unit testing framework
|
||||||
|
|
||||||
|
- Status: accept
|
||||||
|
- Deciders: Arthur Lu, Marc Reta
|
||||||
|
- Date: 11 / 12 / 22
|
||||||
|
|
||||||
|
## Decision Drivers
|
||||||
|
|
||||||
|
- Need specification on how to write unit testing assertion statements
|
||||||
|
- Need framework to perform unit testing quickly for immediate code feedback
|
||||||
|
|
||||||
|
## Considered Options
|
||||||
|
- JUnit5
|
||||||
|
- Jest
|
||||||
|
- Mocha
|
||||||
|
|
||||||
|
## Decision Outcome
|
||||||
|
|
||||||
|
Chosen Option: Mocha because it was significantly faster to run than Jest (1s vs 30s), and can use a variety of assertion styles unlike JUnit5.
|
Loading…
Reference in New Issue
Block a user