ReleaseEngineering/Development Best Practices: Difference between revisions

→‎Auth: use auth0
(→‎Server-side: Update server-side recommendations)
(→‎Auth: use auth0)
 
(4 intermediate revisions by the same user not shown)
Line 37: Line 37:


== Browser-side ==
== Browser-side ==
For browser-side stuff, use JavaScript, without any sort of build or compile stage.
Use https://neutrino.js.org/ or https://reactjs.org/
 
{{note|What JS libraries do we commonly use?}}


= External Dependencies =
= External Dependencies =
* For DB's: MySQL
* For DB's: MySQL or postgres
** If you want to use SQLite for development, that's OK, but be aware that you must test thoroughly on MySQL as well - the two are not the same!
** If you want to use SQLite for development, that's OK, but be aware that you must test thoroughly on MySQL as well - the two are not the same!
* Caching: memcached
* Caching: memcached
* Messaging: rabbitmq
* Messaging: amqp
* Workers: celery


= Resiliency =
= Resiliency =
Think about resiliency from the beginning, as reliable resiliency is generally embedded in the architecture of the tool, making it hard to change later.
Think about resiliency from the beginning, as reliable resiliency is generally embedded in the architecture of the tool, making it hard to change later.
* If you're building a daemon, build it so that it can be restarted it at will without any serious ill effects.
* If you're building a daemon, build it so that it can be restarted it at will without any serious ill effects.
** Add support for gracefully stopping your service so that new versions or configurations can be deployed without downtime
** To this end, do not store state in memory, including in the call stack.  If you have a long-running process that you don't want to restart during a transient failure, then break that task up, persist intermediate state somewhere, and be able to pick up where you left off.  This is often most easily accomplished with an explicit state machine.  It's impossible to achieve with a function.
** To this end, do not store state in memory, including in the call stack.  If you have a long-running process that you don't want to restart during a transient failure, then break that task up, persist intermediate state somewhere, and be able to pick up where you left off.  This is often most easily accomplished with an explicit state machine.  It's impossible to achieve with a function.
* Retry everything: HTTP requests, DB queries, DNS lookups, etc.
* Retry everything: HTTP requests, DB queries, DNS lookups, etc.
Line 78: Line 76:
* Plan to run under mod_wsgi in Apache
* Plan to run under mod_wsgi in Apache
* Plan to run across multiple webheads with dedicated disk, if possible; shared netapp storage is available too if necessary
* Plan to run across multiple webheads with dedicated disk, if possible; shared netapp storage is available too if necessary
== Browser-side ==
* Do not use a complex JS build process.


= Auth =
= Auth =
All LDAP authentication for web apps should be handled by Apache in the releng cluster.  Apache will make the LDAP username -- but not the password -- available to the application.
Authentication should be handled by auth0.


= Documentation =
= Documentation =
Confirmed users
2,456

edits