Branch | Status |
---|---|
master |
|
qa |
|
production |
This is a Rails port of the Java application FedoraIngest.
It has an endpoint that MMS hits (with an items' UUIDs as a parameter). It records the UUID in an internal database.
Then (via DelayedJob):
-
Iterates through those UUIDS and asks MMS for the latest information.
- Asks other services (like Filestore DB) for more information about the item.
-
Turns around and posts that information to Fedora & RELS-EXT Solr
This decouples MMS from direct communication with Fedora in the event of Fedora API changes or downtime.
This application uses docker-compose.yml to for most of what it needs.
As time goes on, we'll Dockerize more dependencies and have docker-compose
be
one-stop shopping for running locally. You can edit code as on your machine and expect it to hot-reload like you usually would.
Forget Docker is there.
- Clone this repo.
- Clone NYPL/fedoracommons-3.4.2-dockerized & NYPL/filestore_databases_docker in the directory above this. (make them siblings of this app)
- In this app's root directory
cp ./.env.example ./.env
and fill it out. (See directions in.env.example
)
- Run
docker-compose up filestore-db postgres
, wait, let the databases be created, and synched/mounted to ./database-data. The output will slow down after ~30 seconds. - Now, in another terminal run
docker-compose run webapp
, this will create the database and run the migrations. - Once the migrations end you can
crtl-z
and stop the services
docker-compose up --scale worker=2
It brings up the following services:
The app reachable at http://localhost:3000. It also spins up 2 workers.
The app's database persists in ./database-data/postgres
of your machine.
Our dockerized Fedora instance reachable at http://localhost:8080.
The app's database persists in ./database-data/postgres
of your machine.
It brings up the moving & still image MySQL filestore databases.
Change your .env
file if you want to connect to a remote filestore.
Run tests through docker-compose:
docker-compose run webapp /bin/bash -c "cd /home/app/fedora_ingest_rails && bundle exec rspec"
Our branches (in order or stability are):
Branch | Environment | AWS Account |
---|---|---|
master | none | none |
qa | qa | nypl-dams-dev |
production | production | nypl-dams-prod |
- Feature branches are cut from
master
. - Once the feature branch is ready to be merged, file a pull request of the branch into master.
- We 'promote' branches by merging from the less mature branch to the more mature branch. (master => qa => production)
We use Travis for continuous deployment. Merging to certain branches automatically deploys to the environment associated to that branch.
Merge from | Into | Deploys to (after tests pass) |
---|---|---|
master |
qa |
qa env |
qa |
production |
production env |
For insight into how CD works look at .travis.yml and the provisioning/travis_ci_and_cd directory. The approach is inspired by this blog post (google cached version).
See Amazon And ECS.
You may want to start a rails console or hit an endpoint for debugging purposes.
See the debugging documentation.