This is the API for the third iteration of the resident support request service.
- .NET Core as a web framework.
- nUnit as a test framework.
- Install Docker.
- Install AWS CLI.
- Clone this repository.
- Rename the initial template.
- Open it in your IDE.
This application is a Visual Studio solution built with C#. It uses Entity Framework. Visual Studio or Rider are therefore recommended over VS Code. Debugging and Entity Framework migrations will potentially require more steps than below for other IDEs.
The application can also be served locally using docker:
- Add you security credentials to AWS CLI.
$ aws configure
- Log into AWS ECR.
$ aws ecr get-login --no-include-email
- Build and serve the application. It will be available in the port 3000.
$ make build && make serve
This will initialise the API on port 3000. This may conflict with other applications, it also doesn't provide debugging capabilities of Visual Studio.
-
Ensure Docker is started and the appSettings connection string matches the cv-19-res-support-v3_dev_database values, which should also be running in Docker.
-
In your Visual Studio/IDE Terminal your current directory should be cv19ResSupportV3 which contains the main .csproj file.
-
Now apply all migrations: This command is for Visual Studio / Mac.
$ dotnet ef database update
You can now run the application in debug mode which will open it on port 5000, allowing breakpoints to be added and hit.
See further information in here which contains information on using a development database in AWS.
We use a pull request workflow, where changes are made on a branch and approved by one or more other maintainers before the developer can merge into master
branch.
Then we have an automated six step deployment process, which runs in CircleCI.
- Automated tests (nUnit) are run to ensure the release is of good quality.
- The application is deployed to development automatically, where we check our latest changes work well.
- We manually confirm a staging deployment in the CircleCI workflow once we're happy with our changes in development.
- The application is deployed to staging.
- We manually confirm a production deployment in the CircleCI workflow once we're happy with our changes in staging.
- The application is deployed to production.
Our staging and production environments are hosted by AWS. We would deploy to production per each feature/config merged into master
branch.
Using FxCop Analysers
FxCop runs code analysis when the Solution is built.
Both the API and Test projects have been set up to treat all warnings from the code analysis as errors and therefore, fail the build.
However, we can select which errors to suppress by setting the severity of the responsible rule to none, e.g dotnet_analyzer_diagnostic.<Category-or-RuleId>.severity = none
, within the .editorconfig
file.
Documentation on how to do this can be found here.
$ make test
- Use nUnit, FluentAssertions and Moq
- Always follow a TDD approach
- Tests should be independent of each other
- Gateway tests should interact with a real test instance of the database
- Test coverage should never go down
- All use cases should be covered by E2E tests
- Optimise when test run speed starts to hinder development
- Unit tests and E2E tests should run in CI
- Test database schemas should match up with production database schema
- Have integration tests which test from the PostgreSQL database to API Gateway
- Record failure logs
- Automated
- Reliable
- As close to real time as possible
- Observable monitoring in place
- Should not affect any existing databases
- Selwyn Preston, Lead Developer at London Borough of Hackney (selwyn.preston@hackney.gov.uk)
- Mirela Georgieva, Lead Developer at London Borough of Hackney (mirela.georgieva@hackney.gov.uk)
- Matt Keyworth, Lead Developer at London Borough of Hackney (matthew.keyworth@hackney.gov.uk)
- Rashmi Shetty, Product Owner at London Borough of Hackney (rashmi.shetty@hackney.gov.uk)