在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:nihp-public/COVID-19-app-iOS-BETA开源软件地址:https://github.com/nihp-public/COVID-19-app-iOS-BETA开源编程语言:Objective-C 77.3%开源软件介绍:NHS COVID-19This application runs in the background and identifies other people running the app within the local area by using low energy Bluetooth. While the app is running permanently in the background, it periodically broadcasts and listens for other Bluetooth-enabled devices (iOS and Android at this time) that also broadcast the same unique identifier. How it worksOur unique identifier is also known as our service characteristic. In the Bluetooth spec, devices can broadcast the availability of services. Each service can have multiple characteristics. We use a characteristic to uniquely identify our service and distinguish from all other sorts of Bluetooth devices. For every device we find with a matching characteristic, we record an identifier for the device we saw, the timestamp, and the RSSI of the Bluetooth signal, which will allow a team later on to determine who was in close proximity to individuals infected with the novel coronavirus. Functionality
DevelopmentSetupcp Sonar/Environments/Sonar.xcconfig.sample .secret/Sonar.xcconfig
./bin/make-environment < Sonar/Environments/environment.json > .secret/Environment.swift
MoreStatusStateMachineTestsTODO https://nshipster.com/swift-gyb/
Registration CanaryThe registration canary is a diagnostic tool that helps assess the health of
both the entire registraton system and APNS. See Setup for Pact TestingRun You can then proceed as indicated in the README of the Swift Pact Consumer library
to create pact tests. A mock service will be spun up for you before tests on If you get an SSL or ATS error when running the tests, re-run Pact Setup ContextContract testing requires a mock server to be running that we can verify contracts against.
This is done by In order to satisfy App Transport Security (ATS) requirements, the setup involves a certificate for localhost that is issued by a Certificate Authority (CA) created for this project, Sonar CA. This is necessary since self-signed certificates are not accepted by ATS. The certificate has a TTL of 2 years. When it expires, you will need to create a new Sonar CA, export the keys and generate a new certificate since we won't be including the CA private key here. This is to avoid any devices being used for testing accidentally becoming vulnerable to MitM. The setup then installs the certificates in the simulator's SQLite trust store database using the ADVTrustStore library. It has been vendored and modified in order to not require user input so we're able to run it in CI. We're then using the UI testing framework, specifically TrustSonarCARootCertTest to trust the Sonar CA root certificate on all booted simulator devices. Pact tests are in a separate scheme since we do need to inject NotificationsThe app currently relies on remote (as opposed to push) notifications,
which we unfortunately have not been able to trigger on the Simulator. Push
notifications (in the form of There are currently a couple ways to do development with remote notifications:
ReleasesCode is truth. See the GitHub Actions configuration for the current behavior of the system. (And please update this documentation if it's wrong!) Continuous DeliveryAll pushes get built (for both simulator and device) and tested (on iOS 12 and
13). The Once the builds are uploaded, they go through App Store processing. Once that finishes, there are some manual steps that need to be done by someone with App Manager+ permissions in App Store Connect in order to release the build to testers:
Branches and Versions and Build Numbers, Oh My!The release process caters for our normal use case, since with trunk-based development and continuous delivery, we can select a specific commit to promote as a production release. However, this optimization means that the process for creating a release that
is not based off trunk ( Deploying to ProductionTo trigger a release manually, set the following environment variables: DEPLOYMENT_TOKEN="" # obtain one from here: https://github.com/settings/tokens
GITHUB_REPOSITORY="nhsx/<repository-name-here>"
DEPLOYMENT_SHA="<sha of commit you want to release>" Run the following command: ./bin/create-deployment <beta/internal/production> Setup/ConfigurationThe app's configuration is driven through three files in the
CI configuration requires the following secrets:
Fastlane MatchSince we don't want to manually upload builds to App Store Connect and we don't want to write that automation ourselves, that pretty much leaves us with fastlane's upload_to_testflight action. Long story short, we need to have a certificate and provisioning profile set up to build the app. These are secrets, and we do not want to expose them to the world. The path of least resistance with Fastlane is to use match, but this conflicts somewhat with our team and development structure - we don't want to force other dev teams to use fastlane or match, so we can't have match manage the setup, and we also don't have a separate repo to use for match[1]. We also want to continue using Xcode's "automatically manage signing" option for development. [1] In hindsight, I wish we had explored this option further, but we have what we have now and it works, although in an unnecessarily complicated manner. In theory, we should be able to use cert and sigh to manage the credentials as secrets, but I was unable to get that to work in CI. (This would really be the ideal way to handle this.) Instead, what we have is a monstrous hack around match, where we keep a stub of the match repo in source and a tar of the certs and profiles as a secret in CI, and then create the match repo in CI. That might not seem too bad, but it's the setup of the match repository that gets hairy. There's undoubtedly a better way to do this, but this works. Here it is from memory, unfortunately, since I didn't write this down either time I set it up:
|
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论