Skip to content
This repository has been archived by the owner on Oct 29, 2024. It is now read-only.

Entwicklerhandbuch

Jump to bottom
Vera Clemens edited this page Apr 12, 2019 · 8 revisions

Entwicklerhandbuch

Coding-Style

Es gibt im Wiki eine weitere Seite mit Coding Conventions. Für Tests sind auch die Richtlinien von http://www.betterspecs.org/ hilfreich.

Beschreibung des Workflows

Deployen einer Änderung

  1. Die Änderung muss auf dem master-Branch committed sein. Es empfiehlt sich nicht, direkt auf dem master-Branch zu arbeiten -- Änderungen sollten zunächst auf einem anderen Branch vorgenommen werden und dann in den master-Branch gemerget werden.

  2. Es muss eine config/deploy.rb-Datei angelegt werden. Es empfiehlt sich, die config/deploy.example.rb-Datei zu kopieren und den eigenen Nutzernamen auf dem Server unter :deploy_user einzutragen.

  3. Eine SSH-Verbindung zum Server muss möglich sein. Dafür muss etwa eine VPN-Verbindung zu vpn.hpi.de bestehen. Es empfiehlt sich vorallem bei größeren Änderungen, zunächst auf den Staging-Server zu deployen, um die Änderungen in realistischer Umgebung zu testen: cap staging deploy

    Dann kann mithilfe des Befehls cap production deploy (mithilfe des Gems capistrano) der aktuelle Stand des master-Branches auf den Server deployed werden. Dabei werden auch automatisch die Gems so installiert, wie in Gemfile.lock beschrieben, und der Server-Prozess (unicorn) auf dem Server neugestartet.

Errbit

In config/initializers/errbit.rb kann die URL einer Errbit-Instanz eingetragen werden. An diese werden dann alle schwerwiegenderen (nicht abgefangenen) Fehler während der Ausführung des Servers gesendet. Aktuell liegt diese Errbit-Instanz unter https://hpi-connect-errbit.herokuapp.com. Dort kann man sich einloggen und die Fehlermeldungen einsehen. Um schneller auf Fehler aufmerksam zu werden, empfiehlt sich auch, dort z.B. eine Weiterleitung in einen Slack-Channel einzurichten.

Testabdeckung

This project uses the simplecov gem which generates a coverage report each time an RSpec run is completed. The report shows how often each line of code in every file is hit by the tests. Ideally, they should all be hit at least once to make sure the tests are able to catch as many mistakes as possible. The test coverage report can be found at coverage/index.html.

Code-Änderungen sollten die Testabdeckung, wenn möglich, nicht senken.

Wartungsaufgaben

Troubleshooting: Logs and restarting the server

Unicorn can be restarted using the command /etc/init.d/unicorn_hpi-career_production restart. Nginx can be restarted using the command /etc/init.d/nginx restart. The most important logs can be found at /var/logs/nginx/error.log and /var/www/hpi-career/current/log/unicorn.log.

Important: The SECRET_KEY_BASE environment variable needs to be set for Unicorn to function correctly. If, for some reason, it becomes unset, the page will display an error message and unicorn.log will show that SECRET_KEY_BASE is missing. The following fix works:

  1. /etc/init.d/unicorn_hpi-career_production stop
  2. export SECRET_KEY_BASE=... (A secret key can be generated with bundle exec rake secret, for example.)
  3. /etc/init.d/unicorn_hpi-career_production start

This causes a short downtime, but is unavoidable, as Unicorn retains its environment variables during hot restarts (using restart). For it to pick up new environment variables, it needs to be shut down fully and started again.

Keeping gems up-to-date

These commands need to be run locally (not on the server).

  1. Run bundle update to update all gems as far as the Gemfile allows. This will update Gemfile.lock.

  2. Run all tests and check if anything stopped working.

  3. If everything is fine, commit and push all changes to (Gemfile and) Gemfile.lock. The next time the project is deployed, Capistrano will automatically update the gems on the server.

Keeping Ruby up-to-date

Ein guter externer Guide findet sich hier.

Zuerst sollte Ruby auf der lokalen Entwicklungsmaschine geupdatet werden:

  1. Informationen über die neue Ruby-Version im Internet herausfinden: wurden etwa Features deprecated, die nun nicht mehr genutzt werden können? Wenn ja, diese jetzt aus der Anwendung entfernen.

  2. Die neue Ruby-Version installieren, entwerder mit rvm, rbenv oder auf einem anderen Weg. Danach bundle install ausführen, um die Gems zu installieren. Ein bundle update ist nicht unbedingt notwendig.

  3. Die neue Ruby-Version in allen relevanten Dateien eintragen, siehe dieser Beispiel-Commit.

  4. Alle Tests ausführen sowie die App lokal testen, um Fehler und Deprecation-Warnungen zu erkennen. Diese müssen behoben werden.

Besteht die Anwendung alle Tests und läuft lokal ohne Probleme, kann nun die Ruby-Version auf dem Server aktualisiert werden. (ab hier ist die Anleitung leider Englisch)

This project uses Ruby Version Manager (RVM) to manage the current Ruby version. All of the following commands need to be executed on the server.

  1. (Not always needed) If the currently installed version of RVM is out of date, it should be updated.

    \curl -sSL https://get.rvm.io | sudo bash -s stable

    rvm reload

  2. Update to the newest available Ruby version and set it as default.

    rvm install 2.x

    rvm --default use 2.x

    (where 2.x is the version you want to update to)

  3. Deploy the changes made to Gemfile etc. above:

    cap production deploy

  4. Copy the gemset.

    rvm gemset copy <previous_version> <new_version>

  5. Done!

Clone this wiki locally