renuo / applications-setup-guide Goto Github PK

Discussion regarding if we want to keep NewRelic or not in our applications

Currently there are broken / outdated links in the ruby on rails setup guide:

• Rack CORS
• Rack Attack

I'd suggest to either remove the two or link them to their respective GitHub repository(if needed).

How do we want to block these bots from triggering 404 exceptions?
Two ideas:

• https://github.com/kickstarter/rack-attack
• Cloudflare rules

Discussion is open. Ideas are welcome.
I'd personally go for the first one to not depend too much on Cloudflare for these things. Also, it acts on middleware level, which is pretty fast and early.

Rubocop added a new rule that suggest using fetch over [] for accessing ENV: https://docs.rubocop.org/rubocop/cops_style.html#stylefetchenvvar

@schmijos @coorasse and I discussed this and came to the conclusion that we'd like to adopt this new rule.

Here are some other notes from the discussion:

• it is good to be reminded to think about defaults when adding new ENV-vars
• figaro (application.yml) should already ensure that a default is present
• using fetch without a fallback value makes it clear that a value has to be set
• using fetch with a fallback value makes it clear when a variable is optional
• when applying the new linter suggestions the choice between with/without fallback value should be made based on the application.yml of the project

Disable RSpec/MultipleExpectations check and enable failures aggregation globally with:

config.define_derived_metadata do |meta|
   meta[:aggregate_failures] = true
end

for decisions, the user could/should make himself, i would like to introduce a command prompt (e.g. https://github.com/JEG2/highline) to let the user know, what the system would do for him. so it's up for the user, if he wants the let the bin/setup change system things. especially:

• changing hosts-file
• set up hooks
• ..

Write a guide on how to write JS tests with Webpacker. Take existing projects as an example. (hillary, xing)

To bring to work <project-name>-<branch>.renuoapp.ch, you have to also configure the domain in heroku. this part is missing.

As discussed in #54

As I already mentioned during the last SCRUM-Meeting I would like to put forward a 'rewrite' of the application setup guide.
For this, I'd propose using a tool like mdBook.

This would result in a printable, searchable and easier to navigate documentation.
Example: https://renuo.github.io/setup-documentation/general/introduction.html.

In addition to this I would like to discuss the following general changes:

Additions:

• https://github.com/palkan/isolator (Detect non-atomic interactions within DB transactions.) (RAILS)
• https://github.com/ankane/strong_migrations (Catch unsafe migrations in development) (RAILS)
• Flutter Application Setup guide

Change:

• I would like to replace rubocop with https://github.com/testdouble/standard
  • Less friction during updates
  • No more configuration difference between projects
  • Trusted by other companies and thus sufficiently test for our usage

Evaluation:

• Do we still need a React Native Project guide? Does management plan to further use the framework?

WARN -- sentry: ** [Raven] You are running on Heroku but haven't enabled Dyno Metadata. 
For Sentry's release detection to work correctly, please run
 `heroku labs:enable runtime-dyno-metadata`

Is this always necessary and could be integrated in the setup guide?

A tracking ticket for my guide on how to setup flutter and use fastlane for deployment

Figaro is not supported anymore (although it still works). This issue opens the discussion to migrate to the maintained dotenv-rails.

Configuring Sentry is a pain and should be automated via CLI: https://docs.sentry.io/cli/

This issue is a suggestion to use always rspec for all our projects. This means to add the -T option when creating the application and adding the rspec-rails gem immediately.