There are a few legacy things that we need to cleanup, we know...
This repo has been built to do several things:
- Create the docker image for the BZFE
- Deploy the latest version of the Unee-T Dashboard (BZFE)
- Facilitate the local installation of a semi-functional Unee-T environment locally (See the Developing locally section below).
- Our code has been built on and for Ubuntu Linux.
- Our code has NOT been tested on other platforms.
- Our code will most likely NOT work on any platform other that Ubuntu at the moment.
- We use docker and docker-compose to containerise each Unee-T component/service
- We use AWS for A LOT of things.
- The current version of the Unee-T code will NOT work as expected if not fully (i.e with all the necessary components and dependencies) deployed on AWS.
- We use Meteor/Mongo for the case interface.
- We use Bugzilla/AuroraDb-MySQL for case management.
- AWS AuroraDb is a MUST since we are using lambdas inside Db events, calls and procedures. The current version of the Unee-T code will NOT work if not on AWS AuroraDb.
- We use Travis CI for Test.
- We use Travis CI for automated deployments.
To develop locally, you need to to start from a primed sql file.
Make sure that the MongoDb and the BzDB are in sync! We try to handle "orphan" ressources graciously but there might be some edge cases that we've missed.
Make sure your local .env is correctly setup.
You can run make .env
to do that
Make sure to have a look at the file ./local-env-setup.bash
first!
Once the environment variables are OK you can run
make up
This will create several services locally:
-
case (MEFE) accessible with your browser at: http://localhost:3000/
-
dasboard (BZFE) accessible with your browser at: http://localhost:8081/
docker-compose up -d db # Just start the database at first, should be empty
mysql -h db -P 3306 -u root --password=$MYSQL_ROOT_PASSWORD bugzilla < dev-backup.sql make up
make down
make clean
make up
WIP - explain how to dump the latest version on the seed database in the local environment.
You want to Aurora's mock mysql.lambda_async.
docker exec -it bugzilla-customisation_bugzilla_1 /bin/bash
innotop -h 127.0.0.1 -P 3306 -u root --password=$MYSQL_ROOT_PASSWORD
docker exec -it bugzilla_bugzilla_1 /bin/bash
cat data/mailer.testfile
-
When you install Unee-T, you are creating a Unee-T Installation.
-
Each Unee-T installation is designed to have 3 different Environments:
- DEV: for test and staging in "Real Life" condition (NOT local)
- PROD: What you will use in production.
- DEMO: A sandboxed environment that is running the same version of the code as the PROD environment.
We are rellying HEAVILY on AWS services like SES, SQS, Lambdas, ECS, etc... This makes local development a bit more difficult.
Each Environment is deployed on a dedicated AWS account. An Installation is linked to 3 different AWS accounts (DEV/STAGING, PROD and DEMO).
Secrets and environment variables are managed in AWS's parameter store.
Consider doing this at a quiet time though not on a Friday afternoon as developers would like to relax typically then like everyone else.
Release manager needs to ensure a seamless UX for the end user by:
- Track and read commits since last release
- Communicate with developers about the current stability and anything pending
- Conduct tests on https://case.demo.unee-t.com/ (often most time consuming job) and try offload this to https://uilicious.com/
- If everything looks good, a judgement call is made and the release is *tagged and pushed
- Follow up: Track the CI/CD actually deployed the changes
- Verify COMMIT in HTML header
curl -s https://case.unee-t.com | grep COMMIT
or try https://version.dev.unee-t.com/ - View ECS events for any issues. Tail logs for anything untoward
- Write release notes aka communicate with users about new features or fixes that make their lives easier
- Solicit feedback from users
Deployments are automated with Travis CI.
- The DEV/STAGING environment is re-deployed/updated each time a commit is pushed to the
master
branch. - The PROD and DEMO environments are re-deployed/updated each time we do a tag release of the
master
branch.
Each components are updated separately. Ex: a push on the master in this repo will only update the BZFE component of the DEV/STAGING environment of the Unee-T installation.
https://github.com/unee-t/frontend/blob/master/backup/ to backup and restore Mongo.
We rely on Bugzilla for several things.
Bugzilla is setup by a variety of sources:
- the initial vanilla stable bugzilla base image
- *-params.json - seemingly just for URL and mailfrom address set via public URLs
- localconfig - created with the start script to set database connection parameters
- bugzilla_admin - for initial administrator user/pass (only used when starting from a blank slate)
- custom skin and templates - set via the Dockerfile
Largely co-ordinated by environment varibles in:
- .env for local
- aws-env.dev for development / testing /staging
- aws-env.prod for production
Note that the BUGZILLA_ADMIN_KEY needs to be in place on the table user_api_keys. Please study how https://github.com/unee-t/reset-demo works.
https://bugzilla.readthedocs.io/en/latest/api/
curl http://localhost:8081/rest/bug/1?api_key=$(aws --profile uneet-dev ssm get-parameters --names BUGZILLA_ADMIN_KEY --with-decryption --query Parameters[0].Value --output text) | jq
There are more examples in Postman.
- ECS overview
- ECS deploy
./deploy.sh
- deploy to staging/development cluster./deploy.sh -p
- deploy to production
Refer to ecs-cli compose service create -h
to create with a load balancer.
SES*
is required for email notifications. SES dashboard
How to test if email is working:
echo -e "Subject: Test Mail\r\n\r\nThis is a test mail" | msmtp --debug -t user@example.com
Video about testing email: https://s.natalian.org/2017-10-27/uneetmail.mp4
How to filter for 5xx errors:
[..., request = *HTTP*, status_code = 5**, , ,]
https://media.dev.unee-t.com/2018-08-23/bugzilla-debug.mp4
https://media.dev.unee-t.com/2018-08-23/targetresponsetime.mp4