¿Cómo crear un website adecuado?

El desarrollo web no es lo que solía ser. Solía ​​consistir en hackear unos pocos scripts PHP (no tengo nada en contra de PHP, en realidad es mi principal lenguaje de progtwigción), uploadlos a través de FTP a un server web y eso fue todo. Hoy, las cosas son más complicadas. Como puedo ver mirando varios sitios web profesionales y modernos (siendo SO el principal, considero SO un gran ejemplo de buenas prácticas en desarrollo web, incluso si está hecho con ASP.NET y alojado en Windows), desarrollando un website es mucho más que eso:

  1. El código del website está realmente en un repository (esa pequeña revisión de svn en el pie de página hace que mis sentimientos nerd se estremezcan);
  2. Los files estáticos (CSS, JavaScript, imágenes) se almacenan en un dominio separado;

Ok, estas fueron mis observaciones. Ahora para mis preguntas:

  1. ¿Qué haces con los files JavaScript y CSS? ¿Simplemente no los mantienes bajo control de versión? Eso parecería estúpido. ¿Crean un repository separado para ellos?
  2. ¿Cómo se configura el repository? ¿Simplemente creas uno en la raíz del server web? ¿O creas algún tipo de disparador post-commit que copy los últimos files en sus destinos apropiados?
  3. ¿Qué sucede si tiene varias máquinas ejecutando el website y desea enviar algunos cambios a todas ellas?
  4. Cada proyecto de este tipo debe tener files de configuration. Estos difieren del repository local al remoto. Por ejemplo, en mi máquina de desarrollo no tengo contraseña de root de MySQL, mientras que en el server de producción ciertamente tengo una contraseña. Esta contraseña se almacenaría en un file de configuration, entre otras cosas, que sería completamente diferente en mi máquina y en el server. Quizás también sean diferentes entre las máquinas de producción (como dije antes, tal vez el website se ejecute en varias máquinas para equilibrar la carga). ¿Cómo manejo eso?

Estoy buscando comenzar un nuevo proyecto web usando:

  • Python + SQLAlchemy + Werkzeug + Jinja2
  • Apache httpd + modwsgi
  • MySQL
  • Mercurial

Lo que me gustaría es un consejo de mejores prácticas sobre el uso de las herramientas antes mencionadas y las respuestas a mis preguntas anteriores.

Tienes razón, las cosas se pueden complicar cuando intentas implementar un website escalable. Estas son algunas de las buenas pautas que he encontrado (descargo de responsabilidad: soy ingeniero de Rails):

  1. La mayoría de las decisiones sobre la estructura de files para el repository de código se basan principalmente en la convención del idioma, el marco y la plataforma que elija implementar. Muchas de las preguntas que planteaste (JS, CSS, activos, producción versus desarrollo) se manejan con Rails. Sin embargo, eso puede diferir de PHP a Python a cualquier otro idioma que desee utilizar. Descubrí que debe investigar sobre el idioma que elige usar y tratar de encontrar la forma de adaptarse a la convención de esa comunidad. Esto lo ayudará cuando intente search ayuda sobre un obstáculo más adelante. Su código se organizará como su código, y podrá get respuestas más fácilmente.

  2. Yo controlaría la versión de todo lo que no sea de gran tamaño. El único problema que he encontrado con VC es cuando tu repo se vuelve grande. Aparte de eso, nunca me arrepentí de tener una versión del código anterior.

  3. Para implementar en varios serveres, hay muchos scripts que pueden ayudarlo a lograr lo que necesita hacer. Para Ruby / Rails, la herramienta más utilizada es Capistrano. También hay resources comparables para otros idiomas. Básicamente solo necesita configurar cómo es la configuration de su server y luego escribir o search en código abierto un set de scripts que pueden desplegar / deshacer / manipular su base de código a los serveres que ha descrito en su file de configuration.

  4. Desarrollo vs Producción es una distinción importante que hacer. Si bien puede operar sin esa distinción, se vuelve engorroso rápidamente cuando tiene que parchear código en todo su repository. Si yo fuera usted, escribiría un código que se ejecuta al comienzo de cada request que determina en qué entorno se está ejecutando. Luego, tendrá ese conocimiento a su disposition mientras procesa esa request. Esta información se puede utilizar cuando se especifica qué configuration desea utilizar cuando se conecta a su database, hasta mostrar la información de debugging en el browser solo en el desarrollo. Resulta útil.

  5. Ser RESTful a menudo dicta gran parte de su layout con respecto a cómo se descubren las páginas de su sitio. Tratar de mantener su código dentro del marco de trabajo reparador le ayuda a recordar dónde se encuentra su código, mantiene su routing pnetworkingecible, evita que su código se acople demasiado y sigue una convención que cada vez es más aceptada. Obviamente, hay otras convenciones que pueden lograr estos mismos objectives, pero he tenido una gran experiencia con REST y ha mejorado mi código sustancialmente.

Todo eso dicho. Descubrí que si bien puede tener buenas intenciones para crear una base de código prístina que puede escalar infinitamente y es agradable y limpia, rara vez resulta de esta manera. Si fuera usted, haría una pequeña cantidad de investigación sobre lo que le parece más cómodo y lo que le ayudará a hacer su vida más fácil, e ir con eso.

¡Espero que eso ayude!

Si bien tengo poca experiencia en el trabajo con las herramientas que mencionas, a exception de MySQL, puedo darte algunas respuestas bastante estándar para las preguntas que publicaste.

1) Depende de los detalles, pero la mayoría de las veces los guardas en el mismo repository pero en una carpeta separada.

2) El hecho de que algo se haya comprometido con el repository no significa que esté listo para entrar en funcionamiento; a menudo es una compilation intermedia que puede estar plagada de errores. Una publicación se realiza manualmente, con una export desde el repository. Configurar el server web en la misma carpeta que svn checkout es una gran nono, ya que la carpeta .svn contiene bastante información sensible, como por ejemplo cómo insert cambios en el server svn.

3) Utiliza algún tipo de solución NAS o SAN, o simplemente un recurso compartido de networking en uno de los serveres, y lee todos sus datos desde allí. De esta forma, cuando envía información a un lugar, todos los serveres pueden acceder a ella. Si su networking es lenta, configura scripts que transfieren los files a todos los serveres automáticamente desde una sola location. Si utiliza un entorno multiserver en ASP.NET, no olvide actualizar la key del equipo en los files de configuration o sus memorys caching cifradas compartidas, como ViewState, no funcionarán en todos los serveres. Tener una tienda de session en una database también es una buena idea.

4) Tengo un paso posterior a la compilation que solo se activa en Publish que reemplaza las cadenas de conexiones de mi database con las de producción, y también cambia el valor de configuration de la aplicación de producción de falso a verdadero en los files web.config / app.config publicados. No veo ningún caso en el que desee diferentes files de configuration para diferentes serveres que sirven el mismo contenido.

Si algo no está claro, solo comente y trataré de aclararlo.

¡Buena suerte! // Eric Johansson

Creo que estás mezclando 2 aspectos diferentes, control de fuente e implementación. El hecho de que tenga todos sus files en un único repository no significa que tengan que implementarse de esa manera. También es discutible si debe implementar directamente mediante el control de código fuente o en su lugar utilizar un script de compilation / implementación que pueda manejar cualquier cantidad de configuraciones.

También el alojamiento de files estáticos en un dominio separado realmente solo vale la pena en sitios web de alto tráfico. ¿Estás seguro de que no estás optimizando prematuramente?