dhvogel / cryptorides-karl Goto Github PK

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Right now I'm putting in console.log() statements ad hoc. A more thought out logging strategy would help me understand more about what's going on at runtime.

Please describe the intended behavior:

Develop and implement a basic logging strategy.

Other information:

This seems like a good starter: https://blog.risingstack.com/node-js-logging-tutorial/

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, jumpbike data is retrieved from the jumpbike API, and jumpbike locations are shown on a Google map.

Please describe the intended behavior:

A full order flow for Jumpbikes should be developed. This means that users should be able to click on any given Jumpbike and reserve it through the cryptobike interface.

Other information:

Jumpbike has a way to do this: https://app.socialbicycles.com/developer/#!/bikes/POST_bikes_bike_id_book_bike_format_post_1

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, there is no minimum standard for testing or really any metrics around how much of the codebase is being tested build to build.

Please describe the intended behavior:

Test reports should be run and archived somewhere. Could be stored in an s3 bucket.

Other information:

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, /jumpbikes/:bikeId uses my client token to book a live jumpbike (and charge me for it).

Please describe the intended behavior:

This should be removed as people could probably book jumpbikes for free should they stumble across this.

This functionality should be kept as part of the jumpbikes module, however people shouldn't be able to do this until first paying in crypto or what have you.

Other information:

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, there exists a nice mocha/chai/sinon unit test suite, but no integration test suite to test endpoints.

Please describe the intended behavior:

An integration test suite should be created.

Other information:

Probably should use supertest.

https://github.com/visionmedia/supertest

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, I'm manually running CI builds on a containerized Jenkins server on my local.

Please describe the intended behavior:

The CI build trigger should be automated, and happen every time code is pushed to cryptobikes.

Other information:

If I want to continue to be cheap and run Jenkins on my local (I do), I could use ngrok (https://ngrok.com/) to give Jenkins a URL access-able by the outside world. I could then add that URL as a webhook to each cryptobikes repository.

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Right now, secrets are read from a config file stored on my local, but not committed to github. This is problematic when docker images are built from source pulled from github.

Please describe the intended behavior:

Docker containers running in the cloud should have access to secrets, like I do on my local. However, this access should be restricted to only the infrastructure on which the cryptobikes services run.

This could be achieved by storing secrets in an s3 bucket, locking down the bucket with a strict bucket policy, and giving the cryptobikes infrastructure IAM roles with permissions necessary to access the bucket.

AWS also just rolled out a "secrets manager" like two weeks ago but I don't know much about it. https://aws.amazon.com/blogs/aws/aws-secrets-manager-store-distribute-and-rotate-credentials-securely/

Other information:

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

For development purposes, I am using the Client Token provided to me by Jumpbike to make Jumpbike API requests.

Please describe the intended behavior:

In traditional OAuth2, a new client token should be generated for each user who authorizes a particular service. This flow should be developed so people can actually use the app.

Other information:

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, the deployment pipeline does the following:

• Unit test
• Lint
• Build Docker Image
• Push Docker Image to Dockyard
• Bump patch version of src
• Push bumped version back to github

Please describe the intended behavior:

The deployment pipeline should also deploy the newly built container into a dev environment. This will require creating a dev environment.

Other information:

Could probably leverage the ALB/ECS terraform I wrote a while back.
https://github.com/dhvogel/cfcorp-tf-aws-alb-ecs

This is a:

• Bug Report
• Feature Request
• Other (please specify):

Please describe the current behavior:

Currently, in each CI build, the old cryptorides stack is completely destroyed and a new cryptorides stack is applied. This means that the IP address of the instance on which cryptorides is hosted is inconsistent across time.

Please describe the intended behavior:

Even though no one is using cryptorides yet, there should be a consistent endpoint for the dev environment.

Other information:

This could be achieved by using r53. https://www.terraform.io/docs/providers/aws/r/route53_record.html