baarkerlounger
3 years ago
2 changed files with 45 additions and 0 deletions
@ -0,0 +1,33 @@ |
|||||||
|
### ADR - 001: Initial Architecture Decisions |
||||||
|
|
||||||
|
##### Application Framework |
||||||
|
|
||||||
|
Ruby on Rails |
||||||
|
- Well established and commonly used within MHCLG and gov.uk in general |
||||||
|
- Good ecosystem for common web app tasks, quick productivity |
||||||
|
- Matches team skill set |
||||||
|
- Analysis/RAP pipelines will sit in the DAP platform and not this application directly so optimising for web framework tasks makes sense. |
||||||
|
|
||||||
|
Testing |
||||||
|
- Rspec for unit testing |
||||||
|
- Capybara or Cypress-Rails for front end testing |
||||||
|
- TDD or ATDD approach |
||||||
|
- No specific code coverage target or deploy gate as we feel this leads to arbitrary metric chasing and is counter-productive |
||||||
|
|
||||||
|
Front end |
||||||
|
- In the same app codebase |
||||||
|
- ERB templates |
||||||
|
|
||||||
|
Code Style & Linting |
||||||
|
- Gov.uk Rubocop for Ruby style |
||||||
|
- .editorconfig for whitespace, newlines etc |
||||||
|
|
||||||
|
|
||||||
|
<br /> |
||||||
|
|
||||||
|
#### Ways of Working |
||||||
|
|
||||||
|
- Flexible approach to branching. Generally Trunk based CI (every TDD round results in a commit and push to master) when pairing, branches and PR when doing solo or more exploratory work. |
||||||
|
- Github actions for automated test, build, deploy pipeline |
||||||
|
- Github actions should run Rubocop, RSpec, Front end tests, docker build and deploy |
||||||
|
- Encourage pairing |
@ -0,0 +1,12 @@ |
|||||||
|
### ADR - 002: Initial Architecture Decisions |
||||||
|
|
||||||
|
#### Repositories |
||||||
|
|
||||||
|
There will be two git repositories for this project. |
||||||
|
|
||||||
|
1. [Infrastructure](https://github.com/communitiesuk/mhclg-data-collection-beta-infrastructure) |
||||||
|
2. Web application (this repository) |
||||||
|
|
||||||
|
This will enable infrastructure and application changes to be worked on somewhat independently more easily as well as avoiding needing to run infrastructure pipeline actions for every application change, given that application changes are likely to be significantly more frequent. |
||||||
|
|
||||||
|
It also reduces complexity for people working on just one or the other. |
Loading…
Reference in new issue