ensl/ensl.org
0
0
Fork 0
mirror of https://github.com/ENSL/ensl.org.git synced 2024-12-27 04:51:14 +00:00
Code Issues Projects Releases Packages Wiki Activity
ensl.org/DEVELOPMENT.md
Ari Timonen 30b9198b6d Add staging that works 
Tune env vars
Fix logs in gitignore
Rename DEPLOY_PATH env var
2020-04-08 22:25:24 +03:00

2.8 KiB
Raw Blame History

Development

Install instructions in INSTALL.md

Bassic commands for development

Load env variables:

source script/env.sh .env .env.development

Start:

docker-compose up --build development`

Build or rebuild:

docker-compose build`

Debug:

docker attach ensl_development

To get inside docker web+test containers:

docker-compose exec -u root web /bin/bash`
docker-compose exec -u web web /bin/bash`
docker-compose exec -u root test /bin/bash`
docker-compose exec -u web test /bin/bash`

Restart the web container

docker-compose restart web`

Run some tests:

docker-compose exec -u web test bundle exec rspec`
docker-compose exec -u web test bundle exec rspec spec/controllers/shoutmsgs_controller_spec.rb`

Tips

  1. If you need to run stuff on your host (eg. ruby, rubocop, bundle install etc) run all commands from the: Dockerfile.dev. It should setup identical setup for your machine.

  2. Add docker container names to /etc/hosts. This makes it possible to run test from local machine without using the container since editor/IDE don't integrate with Docker so well.

    sudo echo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ensl_dev_db db >> /etc/hosts

  3. VS Code and RubyMine are great IDE's/editors.

  4. To run VS Code plugin Ruby Test Explorer in docker container you need to create path to custom path, copy the formatter and it whines about and it still fails a bit.

  5. Do not commit too much without testing. Also keep commits small for documentation and reversability issues.

  6. You need to rebuild the docker image when you change gems.

Design of ENSL Application

Read this to understand design decisions and follow them!

  1. Env variables should be used everywhere and loaded from .env* files using Dotenv
  2. Everything should be running on containers.
  3. Docker-compose is the heart of deployment
  4. Dockerfile should contain the gems and prebuilt assets for production
  5. The app contents are added to the docker image on build but it is mounted as volume. It will override the Dockerfile content.

Tags in code

FIXME, TODO, EXPLAIN, OBSOLETE

TODO issues for dev

  1. Puma should be running (eg. spring), and if debugger is used it should be able to connect via docker-compose up
  2. Should directories exist?
  3. docker-compose has some .env specific vars and then

Best practices

Take a look at these before writing anything.

  1. https://nvie.com/posts/a-successful-git-branching-model/
  2. https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
  3. https://github.com/rubocop-hq/ruby-style-guide
  4. https://rails-bestpractices.com/
  5. http://www.betterspecs.org/
  6. https://github.com/rubocop-hq/rspec-style-guide
  7. Run rubocop