initial commit

1 files changed, 672 insertions, 0 deletions

diff --git a/files/es/learn/server-side/django/deployment/index.html b/files/es/learn/server-side/django/deployment/index.html
new file mode 100644
index 0000000000..ddcb7f5c4e
--- /dev/null
+++ b/files/es/learn/server-side/django/deployment/index.html
@@ -0,0 +1,672 @@
+---
+title: 'Tutorial de Django Parte 11: Desplegando Django a producción'
+slug: Learn/Server-side/Django/Deployment
+translation_of: Learn/Server-side/Django/Deployment
+---
+<div>{{LearnSidebar}}</div>
+
+<div>{{PreviousMenuNext("Learn/Server-side/Django/Testing", "Learn/Server-side/Django/web_application_security", "Learn/Server-side/Django")}}</div>
+
+<p class="summary">Ahora que has creado (y probado) un fantastico sitio web para la <a href="https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Tutorial_local_library_website">Biblioteca Local</a>, querrás instalarlo en un servidor web público de manera que pueda ser accedido por el personal y los miembros de la biblioteca a través de Internet. Este artículo proporciona una visión general de cómo buscar un host para desplegar tu sitio web y de lo que necesitas hacer para conseguir que tu sitio esté listo en producción.</p>
+
+<table class="learn-box standard-table">
+ <tbody>
+  <tr>
+   <th scope="row">Requisitos previos:</th>
+   <td>Completar todos los tutoriales de los temas previos, incluyendo <a href="/en-US/docs/Learn/Server-side/Django/Testing">Django Tutorial Part 10: Testing a Django web application</a>.</td>
+  </tr>
+  <tr>
+   <th scope="row">Objetivo:</th>
+   <td>Aprender ¿cómo? y ¿dónde? puedes puedes desplegar una app de Django en producción.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Introducción">Introducción</h2>
+
+<p>Una vez que tu sitio este terminado (o lo suficientemente terminado como para iniciar una prueba pública) vas a necesitar alojarla en un lugar más público y accesible que tu computadora personal.</p>
+
+<p>Hasta ahora has estado trabajando en un entorno de desarrollo, usando <em>Django development web server </em>para compartir tu sitio con el navegador/red local, y corriendo tu sitio web con configuraciones (inseguras) de desarrollo que exponen la depuración y otra informacion privada. Antes de que puedas alojar tu sitio web externamente, lo primero que tendrás que hacer es:</p>
+
+<ul>
+ <li>Introducir algunos cambios en las configuraciones del proyecto.</li>
+ <li>Elegir un entorno para alojar la aplicacion Django.</li>
+ <li>Elegir un entorno para alojar cualquier archivo estático.</li>
+ <li>Configurar una infraestructura a nivel producción para servir tu sitio web.</li>
+</ul>
+
+<p>Este tutorial provee una guía de opciones para elegir un sitio de alojamiento, una breve descripción general de lo que necesitas hacer para preparar tu aplicación Django en producción, y un ejemplo práctico de cómo instalar el sitio web de LocalLibrary en el servicio de alojamiento en la nube de <a href="https://www.heroku.com/">Heroku</a>.</p>
+
+<h2 id="¿Qué_es_un_entorno_de_producción">¿Qué es un entorno de producción?</h2>
+
+<p>El entorno de producción es el entorno proporcionado por el servidor en el que correrá su sitio web para uso externo. El entorno incluye:</p>
+
+<ul>
+ <li>Equipos en los que el sitio web correrá.</li>
+ <li>Sistema operativo (p.e. Linux, Windows).</li>
+ <li>Lenguajes de programación y librerías sobre las que su sitio web está escrito.</li>
+ <li>Servidor web empleado para servir páginas y otros contenidos (p.e. Nginx, Apache).</li>
+ <li>Servidor de aplicaciones que transmite peticiones "dinámicas" entre su sitio web Django y el servidor web.</li>
+ <li>Bases de datos que su sitio web necesita.</li>
+</ul>
+
+<div class="note">
+<p><strong>Nota</strong>: Dependiendo de como esté configurado su entorno de producción, usted podría disponer también de un proxy inverso, balanceador de carga, etc.</p>
+</div>
+
+<p>El servidor podría estar ubicado en sus propias instalaciones y conectado a Internet a través de un enlace rápido, pero lo más común es utilizar un computador alojado "en la nube". Esto en realidad implica que su código es ejecutado en algún computador remoto (o posiblemente un computador "virtual") en el centro (o centros) de datos de su compañía de servicios de <em>hosting.</em> El servidor remoto normalmente ofrecerá un determinado nivel garantizado de recursos de computación (es decir, CPU, RAM, memoria de almacenamiento, etc) y de conectividad a Internet por un cierto precio.</p>
+
+<p>A este tipo de hardware de computación/comunicaciones accesible de forma remota se le denomina <em>Infrastructure as a Service </em>o<em> Infraestructura como Servicio (IaaS)</em>. Muchos proveedores de IaaS ofrecen la opción de preinstalar un sistema operativo en particular, sobre el cual se debe instalar el resto de componentes de su entorno de producción. Otros permiten seleccionar entornos plenamente configurados, con incluso configuraciones de Django y servidor web establecidas.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Los entornos pre-construidos le permiten establecer su sitio web de manera muy sencilla, ya que reducen el trabajo de configuración, pero las opciones disponibles podrían limitarle al uso de un servidor (u otros componentes) poco conocido, o podrían estar basados en versiones antiguas del Sistema Operativo. A menudo es preferible que uno mismo instale sus propios componentes, de manera que disponga de los que desee, y en el momento que necesite subir el nivel de prestaciones de alguna parte del sistema, tener cierta idea de por dónde empezar</p>
+</div>
+
+<p>Otros proveedores de <em>hosting</em> incluyen Django como parte de una <em>Plataform as a Service </em>o<em> Plataforma como Servicio (PaaS)</em>. En este tipo de <em>hosting</em> no necesita preocuparse de la mayor parte del entorno de producción (servidor web, servidor de aplicaciones, balanceadores de carga), dado que la plataforma host ya se ocupa de todo ello por usted (así como de casi todo lo necesario para escalar su aplicación). Esto hace el despliegue bastante sencillo, puesto que ya solo necesita concentrarse en su aplicación web y no en el resto de la infraestructura de servidor.</p>
+
+<p>Algunos desarrolladores elegirán la mayor flexibilidad ofrecida por una IaaS frente a una PaaS, mientras que otros valorarán el reducido coste general de mantenimiento y la mayor facilidad de escalado de PaaS. Cuando se está empezando, la instalación del sitio web en un sistema PaaS es mucho más sencilla, así que eso es lo que haremos en este tutorial. </p>
+
+<div class="note">
+<p><strong>Consejo:</strong> Si eliges un proveedor de hosting adaptado a Python/Django, éste debería facilitar instrucciones de cómo instalar un sitio web Django usando diferentes configuraciones de servidor web, servidor de aplicaciones, proxy inverso, etc (esto es irrelevante si eliges una PaaS). Por ejemplo, existen muchas guías paso-a-paso para distintas configuraciones en la <a href="https://www.digitalocean.com/community/tutorials?q=django">Digital Ocean Django community docs</a>.</p>
+</div>
+
+<h2 id="Eligiendo_un_proveedor_de_hosting">Eligiendo un proveedor de hosting</h2>
+
+<p>Existen más de 100 proveedores de hosting de los que se sabe que, o bien dan soporte activo, o funcionan bien con Django (puedes encontrar una lista bastante extensa en <a href="http://djangofriendly.com/hosts/">Djangofriendly hosts</a>). Estos proveedores proporcionan diferentes tipos de entornos (IaaS, PaaS), así como diferentes niveles de recursos de computación y comunicaciones a diferentes precios.</p>
+
+<p>Algunos aspectos a considerar al elegir un host son:</p>
+
+<ul>
+ <li>Una estimación de cómo de ocupado va a estar el sitio y el coste de los recursos de datos y computación requeridos para atender esa demanda.</li>
+ <li>Nivel de soporte para el escalado tanto horizontal (añadir más máquinas) como vertical (subir de nivel con máquinas más potentes), y el coste que ello supone.</li>
+ <li>Dónde están ubicados los centros de datos de los proveedores y, por consiguientte, a cuáles será probablemente más rápido el acceso.</li>
+ <li>Los históricos de permanencia en actividad e inactividad del host.</li>
+ <li>Herramientas proporcionadas para la gestión del sitio  — si son fáciles de usar y si son seguras (Por ejemplo, SFTP frente a FTP). </li>
+ <li>Frameworks incorporadas para poder monitorear tu servidor.</li>
+ <li>Limitaciones conocidas. Algunos hosts bloquearán deliberadamente ciertos servicios (por ejemplo, email). Otros ofrecerán solo un cierto número de horas de "tiempo vivo" en determinados niveles de precios, u ofrecerán solo una pequeña cantidad de almacenamiento.</li>
+ <li>Beneficios adicionales. Algunos proveedores pueden ofrecer de forma gratuita nombres de dominio y soporte para certificados SSL por los que, de otro modo, tendrías que pagar.</li>
+ <li>Si el nivel "gratuito" del que dependes expira al cabo de un tiempo, o si el coste de migrar a un nivel más caro puede implicar que sea más conveniente usar algún otro servicio desde el primer momento.</li>
+</ul>
+
+<p>La buena noticia cuando estás en los comienzos es que existen bastantes sitios que proporcionan entornos de computación de "evaluación", "desarrollo" o "de nivel aficionado" de forma gratuita. Se trata siempre de entornos bastantes limitados/restringidos en recursos, y debes estar precavido en que pueden expirar al cabo de un periodo de introducción. Son, no obstante, muy útiles para probar sitios con poco tráfico en un entorno real, y pueden proporcionar una migración sencilla contratando más recursos si el sitio alcanza más ocupación. Entre las opciones conocidas de esta categoría tenemos <a href="https://www.heroku.com/">Heroku</a>, <a href="https://www.pythonanywhere.com/">Python Anywhere</a>, <a href="http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-free-tier.html">Amazon Web Services</a>, <a href="https://azure.microsoft.com/en-us/pricing/details/app-service/">Microsoft Azure</a>, etc. </p>
+
+<p>Muchos proveedores disponen también de un nivel "básico" que proporciona niveles de capacidad de computación más útiles y con menos limitaciones. <a href="https://www.digitalocean.com/">Digital Ocean</a> y <a href="https://www.pythonanywhere.com/">Python Anywhere</a> son ejemplos de proveedores populares de hosting que ofrecen niveles básicos de computación relativamente baratos (en el rango de los 5 a los 10 $USD mensuales).</p>
+
+<div class="note">
+<p><strong>Nota:</strong>  Recuerda que el precio no es el único criterio de selección. Si tu sitio web tiene éxito, la escalabilidad puede convertirse en la consideración más importante.</p>
+</div>
+
+<h2 id="Preparando_tu_sitio_web_para_hacerlo_público">Preparando tu sitio web para hacerlo público</h2>
+
+<p>La <a href="/en-US/docs/Learn/Server-side/Django/skeleton_website">Django skeleton website</a> creada usando las herramientas <em>django-admin </em>y <em>manage.py</em> están configuradas para hacer más sencillo el desarrollo. Muchos de los ajustes del proyecto Django (especificados en <strong>settings.py</strong>) deberían ser distintos en producción, por razones tanto de seguridad como de rendimiento.</p>
+
+<div class="note">
+<p><strong>Consejo:</strong> Es bastante común disponer de un archivo <strong>settings.py</strong> separado en producción, e importar los ajustes sensibles desde un archivo aparte o desde una variable de entorno. Este archivo debería, por tanto, estar protegido, aún cuando el resto del código fuente esté disponible en un repositorio público.</p>
+</div>
+
+<p>Los ajustes críticos que debes comprobar son:</p>
+
+<ul>
+ <li><code>DEBUG</code>. Debería establecerse como <code>False</code> en producción (<code>DEBUG = False</code>). Así se evita que se muestre la traza de depuración sensible/confidencial y la información variable.</li>
+ <li><code>SECRET_KEY</code>. Es un valor aleatorio grande utilizado para la protección CRSF etc. Es importante que la clave utilizada en producción no esté en el control fuente ni accesible desde fuera del servidor de producción. La documentación Django sugiere que debería ser cargada desde una variable de entorno o leída desde un archivo de sólo servicio (<em>serve-only file</em>).</li>
+ <li>
+  <pre class="notranslate"># Read SECRET_KEY from an environment variable
+import os
+SECRET_KEY = os.environ['SECRET_KEY']
+
+#OR
+
+#Read secret key from a file
+with open('/etc/secret_key.txt') as f:
+    SECRET_KEY = f.read().strip()</pre>
+ </li>
+</ul>
+
+<p>Modifiquemos la aplicación <em>LocalLibrary</em> de manera que leamos nuestras variables <code>SECRET_KEY</code> y <code>DEBUG</code> desde variables de entorno si han sido definidas o, en otro caso, usar los valores por defecto del archivo de configuración.</p>
+
+<p><span>Abra </span><strong>/locallibrary/settings.py</strong><span>, deshabilite la configuración original de l </span><code>SECRET_KEY</code><span> y añada las nuevas líneas tal como se muestran abajo en <strong>negrita</strong>. Durante el desarrollo no se especificará ninguna variable de entorno para la clave, por lo que se usará el valor por defecto (no debería importar qué clave utilizas aquí, o si la clave tiene "fugas", dado que no la utilizarás en producción).</span></p>
+
+<pre class="brush: python notranslate"># SECURITY WARNING: keep the secret key used in production secret!
+# SECRET_KEY = 'cg#p$g+j9tax!#a3cup@1$8obt2_+&amp;k3q+pmu)5%asj6yjpkag'
+<strong>import os</strong>
+<strong>SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', 'cg#p$g+j9tax!#a3cup@1$8obt2_+&amp;k3q+pmu)5%asj6yjpkag')</strong>
+</pre>
+
+<p>A continuación, comenta el ajuste de <code>DEBUG</code> existente y añade la nueva línea que se muestra abajo.</p>
+
+<pre class="brush: python notranslate"># SECURITY WARNING: don't run with debug turned on in production!
+# DEBUG = True
+<strong>DEBUG = bool( os.environ.get('DJANGO_DEBUG', True) )</strong>
+</pre>
+
+<p>El valor de <code>DEBUG</code> será <code>True</code> por defecto, pero será <code>False</code> si el valor de la variable de entorno <code>DJANGO_DEBUG</code> se establece como una cadena vacía, es decir, <code>DJANGO_DEBUG=''</code>.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Sería más intuitivo si pudiéramos simplemente marcar y desmarcar la variable de entorno <code>DJANGO_DEBUG</code> a <code>True</code> y <code>False</code> directamente, en lugar de usar "cualquier cadena" o "cadena vacía" (respectivamente). Por desgracia, los valores de las variables de entorno son almacenados como cadenas de Python (<em>Python strings</em>), y la única cadena que se evalúa como <code>False</code> es la cadena vacía (por ejemplo, <code>bool('')==False</code>).</p>
+</div>
+
+<p><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/checklist/">Deployment checklist</a> (Django docs) proporciona una lista de comprobación completa de ajustes que podrías querer cambiar. Puedes también sacar una lista de algunos de ellos usando el siguiente comando de terminal:</p>
+
+<pre class="brush: python notranslate">python3 manage.py check --deploy
+</pre>
+
+<h2 id="Ejemplo_Instalando_LocalLibrary_en_Heroku">Ejemplo: Instalando LocalLibrary en Heroku</h2>
+
+<p>Esta sección aborda una demostración práctica de cómo instalar <em>LocalLibrary</em> en <a href="http://heroku.com">Heroku PaaS cloud</a>.</p>
+
+<h3 id="¿Por_qué_Heroku">¿Por qué Heroku?</h3>
+
+<p>Heroku es uno de los servicios PaaS basados en la nube más duraderos y conocidos. Originalmente únicamente daba soporte a aplicaciones Ruby, pero actualmente puede utilizarse para aplicaciones host de muchos entornos de programación, incluido Django!</p>
+
+<p>Vamos a elegir Heroku por varias razones:</p>
+
+<ul>
+ <li>Heroku tiene un nivel gratuito (<a href="https://www.heroku.com/pricing">free tier</a>) que es <em>verdaderamente</em> gratuito (aunque con algunas limitaciones).</li>
+ <li>Como PaaS, Heroku se hace cargo de gran parte de la infraestructura web por nosotros. Esto hace mucho más sencillos los comienzos, al no tener que preocuparnos por servidores, balanceadores de carga, proxys inversos, o cualquier otro aspecto de la infraestructura web, de los que Heroku se ocupa por nosotros en un segundo plano.</li>
+ <li>Aunque tenga algunas limitaciones, éstas no afectarán a nuestra aplicación particular. Por ejemplo:
+  <ul>
+   <li>Heroku sólo proporciona almacenamiento efímero, por lo que los archivos subidos por el usuario no pueden almacenarse de forma segura en el propio Heroku.</li>
+   <li>El nivel gratuito mantendrá dormida cualquier aplicación web inactiva que no haya tenido requerimientos dentro de un periodo de media hora. El sitio puede tardar varios segundos en responder cuando se le despierte.</li>
+   <li>El nivel gratuito limita el tiempo que el sitio puede estar en ejecución a cierta cantidad de horas al mes (sin contar el tiempo que el sitio permanece "dormido"). Esto está bien para un sitio de poco uso o de demostración, pero no es asumible si se necesita una disponibilidad del 100%. </li>
+   <li>Otras limitaciones se relacionan en <a href="https://devcenter.heroku.com/articles/limits">Limits</a> (Heroku docs).</li>
+  </ul>
+ </li>
+ <li>Lo principal es que funciona, y si te termina gustando, escalar tus aplicaciones será muy sencillo.</li>
+</ul>
+
+<p>Si bien Heroku es perfecto para alojar esta demostración, puede no serlo para tu sitio web real. Heroku facilita la instalación y el escalado, a costa de ser menos flexible, y potencialmente mucho más caro una vez que abandonas el nivel gratuito.</p>
+
+<h3 id="¿Cómo_funciona_Heroku">¿Cómo funciona Heroku?</h3>
+
+<p>Heroku ejecuta sitios web Django dentro de uno o más "<a href="https://devcenter.heroku.com/articles/dynos">Dynos</a>", que son contenedores Unix virtualizados y aislados que proporcionan el entorno necesario para ejecutar una aplicación. Los dynos están completamente aislados y disponen de un sistema de archivos <em>efímero</em> (sistema de archivos de vida corta que es limpiado/vaciado cada vez que el dyno se reinicia). Lo único que los dynos comparten por defecto son las variables de configuración (<a href="https://devcenter.heroku.com/articles/config-vars">configuration variables</a>) de las aplicaciones. Heroku utiliza interrnamente un balanceador de carga para distribuir el tráfico web entre todas las dynos "web". Puesto que no se comparte nada entre ellas, Heroku puede escalar una app horizontalmente simplemente añadiendo más dynos (aunque, claro está, podrías necesitar escalar tu base de datos para aceptar conexiones adicionales).</p>
+
+<p>Puesto que el sistema de archivos es efímero, no puedes instalar los servicios requeridos por tu aplicación directamente (por ejemplo, bases de datos, colas, sistemas de cacheado, almacenamiento, servicios de correo electrónico, etc). En su lugar, las aplicaciones web de Heroku usan servicios de respaldo proporcionados por Heroku o terceros como "add-ons" independientes. Una vez adjuntados a tu aplicación web, los dynos acceden a los servicios usando la información contenida en las variables de configuración de la aplicación.</p>
+
+<p>Para ejecutar tu aplicación, Heroku necesita poder instalar el entorno y las dependencias adecuados, y entender cómo están enlazados. Para las apps Django, esta información se proporciona en una serie de archivos de texto:</p>
+
+<ul>
+ <li><strong>runtime.txt</strong>:<strong> </strong>el lenguaje de programación y la versión a utilizar.</li>
+ <li><strong>requirements.txt</strong>: dependiencias de los componentes de Python, incluyendo a Django.</li>
+ <li><strong>Procfile</strong>: Lista de procesos que han de ejecutarse para arrancar la aplicación web. Para Django, esto será normalmente el servidor de aplicaciones web Gunicorn (con un script .wsgi).</li>
+ <li><strong>wsgi.py</strong>: Configuración <a href="http://wsgi.readthedocs.io/en/latest/what.html">WSGI</a> para invocar a nuestra aplicación Django en el entorno Heroku.</li>
+</ul>
+
+<p>Los desarrolladores interactúan con Heroku usando una app/terminal cliente especial, algo muy parecido a un bash script de Unix. Esto permite subir código almacenado en un repositorio git, inspeccionar los procesos en ejecución, ver logs, establecer variables de configuración, y mucho más!.</p>
+
+<p>Para conseguir nuestra aplicación para trabajar en Heroku, necesitaremos colocar nuestra aplicación web Django dentro de un repositorio git, añadir los archivos anteriores, integrar con una base de datos add-on, y hacer cambios para manejar correctamente los archivos estáticos.</p>
+
+<p>Una vez hecho todo eso, podemos crear una cuenta Heroku, obtener el cliente Heroku, y usarlo para instalar nuestro sitio web.</p>
+
+<div class="note">
+<p><strong>Nota: </strong>Las instrucciones indicadas abajo reflejan la forma de trabajar con Heroku en el momento de la redacción. Si Heroku cambia sus procesos de forma significativa, podrías preferir, en su lugar, revisar su documentación de instalación: <a href="https://devcenter.heroku.com/articles/getting-started-with-python#introduction">Getting Started on Heroku with Django</a>.</p>
+</div>
+
+<p>Con esto ya tienes una visión general de lo que necesitas para empezar (vea <a href="https://devcenter.heroku.com/articles/how-heroku-works">How Heroku works</a> para tener una guía más exhaustiva).</p>
+
+<h3 id="Creando_un_repositorio_de_aplicación_en_Github">Creando un repositorio de aplicación en Github</h3>
+
+<p>Heroku está estrechamente integrado con el sistema de control de versiones de código fuente <strong>git</strong>, usándolo para subir/sincronizar cualquier cambio que hagas en los sistemas activos. Esto se hace añadiendo un nuevo repositorio "remoto" heroku denominado <em>heroku</em> que apunta a un repositorio para tu fuente en la nube Heroku. Durante el desarrollo usas git para almacenar los cambios en tu repositorio "maestro". Cuando quieras desplegar tu sitio, sincronizas tus cambios con el repositorio Heroku.</p>
+
+<div class="note">
+<p><strong>Nota:</strong> Si estás acostumbrado a seguir buenas prácticas de desarrollo de software, probablemente ya estás usando git o algún otro sistema SCM. Si ya dispones de un repositorio git, podrás saltarte este paso.</p>
+</div>
+
+<p>Existen muchas formas de trabajar con git, pero una de las más sencillas es crear en primer lugar una cuenta en <a href="https://github.com/">Github</a>, crear allí el repositorio, y a continuación sincronizarlo localmente:</p>
+
+<ol>
+ <li>Visita <a href="https://github.com/">https://github.com/</a> y crea una cuenta.</li>
+ <li>Una vez conectado, haz click en el enlace  <strong>+</strong> de la barra de tareas superior y selecciona <strong>New repository</strong>.</li>
+ <li>Rellena todos los campos de este formulario. Aunque no son obligatorios, es muy recomendable que los rellenes todos.
+  <ul>
+   <li>Introduce el nombre del nuevo repositorio (por ejemplo, <em>django_local_library</em>), y una descripción (por ejemplo "Sitio web de la Biblioteca Local escrita en Django").</li>
+   <li>Selecciona <strong>Python</strong> en la lista de selección <em>Add .gitignore.</em></li>
+   <li>Selecciona tu licencia en la lista de selección <em>Add license</em>.</li>
+   <li>Marca <strong>Initialize this repository with a README</strong>.</li>
+  </ul>
+ </li>
+ <li>Pulsa <strong>Create repository</strong>.</li>
+ <li>Haz click en el botón verde "<strong>Clone or download</strong>" en la página de tu nuevo repositorio.</li>
+ <li>Copia el valor de la URL del campo de texto situado dentro de la caja de diálogo que aparece (debería decir algo como: <strong>https://github.com/<em>&lt;your_git_user_id&gt;</em>/django_local_library.git</strong>).</li>
+</ol>
+
+<p>Ahora que el repositorio ("repo") ha sido creado, querremos clonarlo en nuestra computadora local:</p>
+
+<ol>
+ <li>Instala <em>git</em> para tu computadora local (puedes encontrar versiones para distintas plataformas <a href="https://git-scm.com/downloads">here</a>).</li>
+ <li>Abre una ventana/terminal de comandos y clona tu repositorio usando la URL que copiaste anteriormente:
+  <pre class="brush: bash notranslate">git clone https://github.com/<strong><em>&lt;your_git_user_id&gt;</em></strong>/django_local_library.git
+</pre>
+  Esto creará el repositorio debajo del punto actual.</li>
+ <li>Navega dentro del nuevo repositorio.
+  <pre class="brush: bash notranslate">cd django_local_library.git</pre>
+ </li>
+</ol>
+
+<p>El paso final es copiar en él tu aplicación y a continuación añadir los archivos a tu repositorio usando git:</p>
+
+<ol>
+ <li>Copia tu aplicación Django en esta carpeta (todos los archivos que estén al mismo nivel que <strong>manage.py</strong> y por debajo, <strong>no</strong> su carpeta locallibrary contenedora). </li>
+ <li>Abre el archivo <strong>.gitignore</strong>, copia las siguientes líneas al final del mismo, y guárdalo (este archivo se utiliza para identificar los archivos que, por defecto, no deberían subirse a git).
+  <pre class="notranslate"># Text backup files
+*.bak
+
+#Database
+*.sqlite3</pre>
+ </li>
+ <li>Abre una ventana/terminal de comandos y utiliza el comando <code>add</code> para añadir todos los archivos a git.
+  <pre class="brush: bash notranslate">git add -A
+</pre>
+ </li>
+ <li>Utiliza el comando status para comprobar que todos los archivos que vas a añadir son correctos (quieres incluir ficheros fuentes, no binarios, archivos temporales, etc). Debería tener un aspecto similar a la lista siguiente.
+  <pre class="notranslate">&gt; git status
+On branch master
+Your branch is up-to-date with 'origin/master'.
+Changes to be committed:
+  (use "git reset HEAD &lt;file&gt;..." to unstage)
+
+        modified:   .gitignore
+        new file:   catalog/__init__.py
+        ...
+        new file:   catalog/migrations/0001_initial.py
+        ...
+        new file:   templates/registration/password_reset_form.html</pre>
+ </li>
+ <li>Si estás conforme, consolida tus archivos en el repositorio local:
+  <pre class="brush: bash notranslate">git commit -m "First version of application moved into github"</pre>
+ </li>
+ <li>A continuación, sincroniza tu repositorio local con el sitio web Github, usando lo siguiente:
+  <pre class="notranslate">git push origin master</pre>
+ </li>
+</ol>
+
+<p>Una vez completada esta operación, deberías poder regresar a la página de Github donde creaste tu repositorio, refrescar la página, y comprobar que tu toda tu aplicación ha sido ya cargada. Puedes continuar actualizando tu repositorio según vayan cambiando los archivos, usando este ciclo add/commit/push.</p>
+
+<div class="note">
+<p><strong>Consejo:</strong> Este es un buen momento para hacer una copia de seguridad de tu proyecto "simple" — algunos de los cambios que vamos a ir haciendo en las siguientes secciones podrían ser útiles para el despliegue en cualquier plataforma (o para el desarrollo), pero otros no.</p>
+
+<p>La <em>mejor </em>manera de hacer esto es usar <em>git</em> para gestionar tus revisiones. Con <em>git</em> puedes no solo volver a una versión anterior en particular, sino que puedes mantener ésta en una "rama" separada de tus cambios en producción, y seleccionar determinados cambios a trasladar entre las ramas de producción y desarrollo. <a href="https://help.github.com/articles/good-resources-for-learning-git-and-github/">Learning Git</a> merece la pena el esfuerzo, pero queda fuera del alcance de este tema.</p>
+
+<p>La forma <em>más fácil </em>de hacer ésto es simplemente copiar tus archivos en otra ubicación. Usa la manera que más se ajuste a tus conocimientos de git!</p>
+</div>
+
+<h3 id="Actualizar_la_app_para_Heroku">Actualizar la app para Heroku</h3>
+
+<p>Esta sección explica los cambios que necesitaras hacer a nuestra aplicación <em>LocalLibrary</em> para ponerla a funcionar en Heroku. Mientras que las instrucciones disponibles en <a href="https://devcenter.heroku.com/articles/getting-started-with-python#introduction">Getting Started on Heroku with Django</a> de Heroku asumen que también vas a utilizar el cliente Heroku para ejecutar el entorno de desarrollo local, los cambios que aquí se reflejan son compatibles con el servidor de desarrollo Django existente y las formas de funcionamiento que ya hemos aprendido.</p>
+
+<h4 id="Procfile">Procfile</h4>
+
+<p>Crea el archivo <code>Procfile</code> (sin extensión) en la carpeta raíz de tu repositorio GitHub para declarar los tipos de procesos de la aplicación y los puntos de entrada. Copia en él el texto siguiente:</p>
+
+<pre class="notranslate">web: gunicorn locallibrary.wsgi --log-file -</pre>
+
+<p>La palabra "<code>web:</code>" le dice a Heroku que se trata de una web dyno y puede ser enviada a través del tráfico HTTP. El proceso a arrancar en este dyno es <em>gunicorn</em>, un servidor de aplicaciones web popular recomendado por Heroku. Arrancamos Gunicorn usando la información de configuración que se encuentra en el módulo <code>locallibrary.wsgi</code> (creado con nuestro esqueleto de aplicación: <strong>/locallibrary/wsgi.py</strong>).</p>
+
+<h4 id="Gunicorn">Gunicorn</h4>
+
+<p><a href="http://gunicorn.org/">Gunicorn</a> es el servidor HTTP recomendado para usar con Django en Heroku (tal como se indicaba en el Procfile anterior). Es un servidor HTTP puro-Python para aplicaciones WSGI que puede ejecutar múltiples procesos Python concurrentes dentro de un único dyno (para obtener más información, véase <a href="https://devcenter.heroku.com/articles/python-gunicorn">Deploying Python applications with Gunicorn</a>).</p>
+
+<p>Aunque no necesitaremos <em>Gunicorn</em> para servir nuestra aplicación LocalLibrary durante el desarrollo, lo instalaremos de manera que sean parte de nuestros <a href="#requirements">requerimientos</a> de Heroku para instalar en el servidor remoto.</p>
+
+<p>Instala <em>Gunicorn</em> localmente usando <em>pip</em> en la línea de comandos (que instalamos en <a href="/en-US/docs/Learn/Server-side/Django/development_environment">setting up the development environment</a>):</p>
+
+<pre class="brush: bash notranslate">pip3 install gunicorn
+</pre>
+
+<h4 id="Configuración_de_la_Base_de_Datos">Configuración de la Base de Datos</h4>
+
+<p>No podemos usar la base de datos por defecto SQLite en Heroku dado que está basada-en-fichero, y sería borrada del sistema de archivos <em>efímero</em> cada que se reiniciara la aplicación (normalmente una vez al día, y cada vez que la aplicación o sus variables de configuración fueran modificadas).</p>
+
+<p>El mecanismo de Herocu para gestionar esta situación es usar una <a href="https://elements.heroku.com/addons#data-stores">database add-on</a> y configurar la aplicación web utilizando información de una <a href="https://devcenter.heroku.com/articles/config-vars">variable de configuración</a> del entorno, establecida por la add-on. Existen numerosas opciones de bases de datos, pero nosotros utilizaremos el <a href="https://devcenter.heroku.com/articles/heroku-postgres-plans#plan-tiers">nivel hobby tier</a> de la base de datos <em>Heroku postgres</em> ya que es gratuita, soportada por Django, e incorporada en nuestra nuevas apps Heroku al usar el nivel gratuito plan dyno hobby.</p>
+
+<p>La información de conexión a la base de datos es proporcionada a la web dyno usando una variable de configuración denominada <code>DATABASE_URL</code>. En lugar de codificar esta información en Django, Heroku recomienda que los desarrolladores utilicen el paquete <a href="https://warehouse.python.org/project/dj-database-url/">dj-database-url</a> para extraer la variable de entorno <code>DATABASE_URL</code> y automáticamente convertirla al formato de configuración deseado por Django. Además para instalar el paquete <em>dj-database-url</em> necesitaremos también instalar <a href="http://initd.org/psycopg/">psycopg2</a>, ya que Django lo necesita para interactuar con la base de datos Postgres.</p>
+
+<h5 id="dj-database-url_Configuración_de_base_de_datos_de_Django_a_partir_de_una_variable_de_entorno">dj-database-url (Configuración de base de datos de  Django a partir de una variable de entorno)</h5>
+
+<p>Instala <em>dj-database-url</em> a nivel local para que se convierta en parte de nuestros <a href="#requirements">requerimientos</a> para instalar Heroku en el servidor remoto:</p>
+
+<pre class="notranslate">$ pip3 install dj-database-url
+</pre>
+
+<h5 id="settings.py">settings.py</h5>
+
+<p>Abre <strong>/locallibrary/settings.py</strong> y copia la siguiente configuración al final del archivo:</p>
+
+<pre class="notranslate"># Heroku: Update database configuration from $DATABASE_URL.
+import dj_database_url
+db_from_env = dj_database_url.config(conn_max_age=500)
+DATABASES['default'].update(db_from_env)</pre>
+
+<div class="note">
+<p><strong>Nota:</strong></p>
+
+<ul>
+ <li>Nosotros seguiremos utilizando SQLite durante el desarrollo porque la variable de entorno <code>DATABASE_URL</code> no será fijada en nuestra computadora de desarrollo.</li>
+ <li>El valor <code>conn_max_age=500</code> hace que la conexión sea persistente, lo que es más eficiente que recrear la conexión en cada ciclo de petición. No obstante, esto es opcional y puede ser eliminado si es necesario.</li>
+</ul>
+</div>
+
+<h5 id="psycopg2_soporte_a_la_base_de_datos_Python_Postgres">psycopg2 (soporte a la base de datos Python Postgres)</h5>
+
+<p>Django necesita <em>psycopg2</em> para trabajar con las bases de datos Postgres y tú necesitarás añadir esto a los <a href="#requirements">requirements.txt</a> para que Heroku lo instale en el servidor remoto (como se expone más adelante en la sección de requerimientos).</p>
+
+<p>Django utilizará la base de datos SQLite en modo local por defecto, porque la variable de entorno <code>DATABASE_URL</code> no está establecida en nuestro entorno local. Si quieres cambiar a Postgres completamente y usar nuestra base de datos del nivel gratuito de Heroku tanto en desarrollo como en producción, puedes hacerlo. Por ejemplo, para instalar psycopg2 y sus dependencias localmente en un sistema basado en Linux, usarías los siguientes comandos bash/terminal:</p>
+
+<pre class="brush: bash notranslate"><code>sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib</code>
+pip3 install psycopg2
+</pre>
+
+<p>Puedes encontrar instrucciones de instalación para el resto de plataformas en <a href="http://initd.org/psycopg/docs/install.html">psycopg2 website</a>.</p>
+
+<p>No obstante, esto no es necesario — no necesitas tener activa PostGreSQL en el equipo local, en tanto que se lo indicas a Heroku como requerimiento, en <code>requirements.txt</code> (ver a continuación).</p>
+
+<h4 id="Sirviendo_ficheros_estáticos_en_producción">Sirviendo ficheros estáticos en producción</h4>
+
+<p>Durante el desarrollo utilizábamos Django y el servidor web de desarrollo de Django para servir nuestros ficheros estáticos (CSS, JavaScript, etc). En un entorno de producción normalmente se sirven los ficheros estáticos desde una red de entrega de contenidos (CDN, Content Delivery Network) o desde el servidor web.</p>
+
+<div class="note">
+<p><strong>Nota:</strong> Servir ficheros estáticos vía Django/aplicación web es ineficiente ya que las peticiones tienen que pasar por código adicional innecesario (Django), en vez de ser gestionados directamente por el servidor web o una CDN completamente independiente. Si bien esto no tiene relevancia en el uso local durante el desarrollo, el uso de este mecanismo en producción tiene un significativo impacto de rendimiento. </p>
+</div>
+
+<p>Para facilitar el alojamiento de archivos estáticos de forma separada de la aplicación web Django, Django proporciona la herramienta <em>collectstatic</em> para recoger estos archivos para el despliegue (hay una variable de configuración que define de dónde se deben recopliar los archivos cuando se ejecuta <em>collectstatic</em>). Las plantillas Django hacen referencia a la localización de almacenamiento de los archivos estáticos en relación a una variable de configuración (<code>STATIC_URL</code>), por tanto, esto puede modificarse se los archivos estáticos son movidos a otro host/servidor.</p>
+
+<p>Las variables de configuración más relevantes son:</p>
+
+<ul>
+ <li><code>STATIC_URL</code>:  Es la localización URL base desde la cual se servirán los archivos estáticos, por ejemplo en una CDN. Se usa para variables de plantilla estáticas a las que se acceden en nuestra plantilla base (ver <a href="/en-US/docs/Learn/Server-side/Django/Home_page">Django Tutorial Part 5: Creating our home page</a>).</li>
+ <li><code>STATIC_ROOT</code>: Es la ruta absoluta a un directorio en el que la herramienta "collectstatic" de Django reunirá todos los archivos estáticos referenciados en nuestras plantillas. Una vez recopilados, podrán ser cargados como un grupo a donde hayan de ser alojados.</li>
+ <li><code>STATICFILES_DIRS</code>: Relaciona directorios adicionales en los que la herramienta collestatic de Django debería buscar archivos estáticos.</li>
+</ul>
+
+<h5 id="settings.py_2">settings.py</h5>
+
+<p>Abra <strong>/locallibrary/settings.py</strong> y copie la configuración siguiente al final del archivo. La variable <code>BASE_DIR</code> debería haber sido ya definida en tu fichero (la variable <code>STATIC_URL</code> puede haber sido ya definida dentro del archivo cuando fue creado. Puesto que no provocará ningún fallo, podrías borrar la referencias duplicadas).</p>
+
+<pre class="notranslate"># Static files (CSS, JavaScript, Images)
+# https://docs.djangoproject.com/en/1.10/howto/static-files/
+
+# The absolute path to the directory where collectstatic will collect static files for deployment.
+STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
+
+# The URL to use when referring to static files (where they will be served from)
+STATIC_URL = '/static/'
+</pre>
+
+<p>Nosotros haremos el servicio de ficheros utilizando una librería denominada <a href="https://warehouse.python.org/project/whitenoise/">WhiteNoise</a>, que instalaremos y configuraremos en la siguiente sección.</p>
+
+<p>Para más información, vea <a href="https://devcenter.heroku.com/articles/django-assets">Django and Static Assets</a> (Heroku docs).</p>
+
+<h4 id="Whitenoise">Whitenoise</h4>
+
+<p>Hay muchas formas de servir ficheros estáticos en producción (ya vimos los ajustes Django relevantes en las secciones previas). Heroku recomienda usar el proyecto <a href="https://warehouse.python.org/project/whitenoise/">WhiteNoise</a> para servir objetos estáticos directamente desde Gunicorn en producción.</p>
+
+<div class="note">
+<p><strong>Nota: </strong>Heroku llama automáticamente a <em>collectstatic</em> y prepara tus ficheros estáticos para ser usados por WhiteNoise después de que se cargue tu aplicación. Revisa la documentación <a href="https://warehouse.python.org/project/whitenoise/">WhiteNoise</a>, en la que se explica cómo funciona y por qué la implementación es un método para servir estos ficheros relativamente eficiente.</p>
+</div>
+
+<p>Los pasos para instalar <em>WhiteNoise</em> para usarlo dentro del proyecto son:</p>
+
+<h5 id="WhiteNoise">WhiteNoise</h5>
+
+<p>Instala WhiteNoise localmente usando el siguiente comando:</p>
+
+<pre class="notranslate">$ pip3 install whitenoise
+</pre>
+
+<h5 id="settings.py_3">settings.py</h5>
+
+<p>Para instalar <em>WhiteNoise</em> en tu aplicación Django, abre <strong>/locallibrary/settings.py</strong>, busca la opción <code>MIDDLEWARE</code> y añade <code>WhiteNoiseMiddleware</code> cerca de la parte superior de la lista, justo debajo de <code>SecurityMiddleware</code>:</p>
+
+<pre class="notranslate">MIDDLEWARE = [
+    'django.middleware.security.SecurityMiddleware',
+    <strong>'whitenoise.middleware.WhiteNoiseMiddleware',</strong>
+    'django.contrib.sessions.middleware.SessionMiddleware',
+    'django.middleware.common.CommonMiddleware',
+    'django.middleware.csrf.CsrfViewMiddleware',
+    'django.contrib.auth.middleware.AuthenticationMiddleware',
+    'django.contrib.messages.middleware.MessageMiddleware',
+    'django.middleware.clickjacking.XFrameOptionsMiddleware',
+]
+</pre>
+
+<p>Opcionalmente, puedes reducir el tamaño de los ficheros estáticos al ser servidos (lo que lo hace más eficiente). Añade lo siguiente al final de <strong>/locallibrary/settings.py</strong>:</p>
+
+<pre class="notranslate"># Simplified static file serving.
+# https://warehouse.python.org/project/whitenoise/
+STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
+</pre>
+
+<h4 id="Requerimientos">Requerimientos</h4>
+
+<p>Los requerimientos Python de tu aplicación web deben ser almacenados en un archivo <strong>requirements.txt</strong> en la carpeta raíz de tu repositorio. Heroku los instalará cuando reconstruya tu entorno. Puedes crear este archivo utilizando <em>pip</em> en la línea de comandos (ejecuta los siguiente en la raíz del repositorio):</p>
+
+<pre class="brush: bash notranslate">pip3 freeze &gt; requirements.txt</pre>
+
+<p>Después de instalar todas las dependencias anteriores, tu archivo <strong>requirements.txt</strong> debería tener <em>al menos</em> estos objetos (aunque los números de versión pueden ser diferentes). Por favor, borra cualquier otra dependencia no listada abajo, a menos que la hayas añadido explícitamente para esta aplicación.</p>
+
+<pre class="notranslate">dj-database-url==0.4.1
+Django==1.10.2
+gunicorn==19.6.0
+<strong>psycopg2==2.6.2</strong>
+whitenoise==3.2.2
+</pre>
+
+<div class="note">
+<p>Asegúrate de que existe una línea <strong>psycopg2</strong> como la que se ve arriba! Incluso aunque no lo hayas instalado localmente, deberías añadirla a <strong>requirements.txt</strong>.</p>
+</div>
+
+<h4 id="Runtime">Runtime</h4>
+
+<p>El archivo <strong>runtime.txt</strong>, si ha sido definido, le dice a Heroku que lenguaje de programación usar. Crea el archivo en el raíz del repositorio y añade el siguiente texto:</p>
+
+<pre class="notranslate">python-3.5.2</pre>
+
+<div class="note">
+<p><strong>Nota:</strong> Heroku sólo soporta un número pequeño de <a href="https://devcenter.heroku.com/articles/python-support#supported-python-runtimes">Python runtimes</a>. Tú puedes especificar valores de runtime de Python 3, pero en el momento de esta redacción la versión anterior será soportada como definida.</p>
+</div>
+
+<h4 id="Guardar_los_cambios_en_Github_y_volver_a_probar.">Guardar los cambios en Github y volver a probar.</h4>
+
+<p>A continuacion, guardemos nuestros cambios en Github. En el terminal (dentro de nuestro respositorio), introduce los comandos siguientes:</p>
+
+<pre class="brush: python notranslate">git add -A
+git commit -m "Added files and changes required for deployment to heroku"
+git push origin master</pre>
+
+<p>Antes de continuar, probemos de nuevo nuestro sitio localmente y asegurémonos de que no ha sido afectado por ninguno de los cambios anteriores. Pon en marcha el servidor web de desarrollo de la forma habitual y comprueba que el sitio aún funciona como esperas en tu navegador.</p>
+
+<pre class="brush: bash notranslate">python3 manage.py runserver</pre>
+
+<p>Ya deberíamos estar preparados para empezar a desplegar LocalLibrary en Heroku.</p>
+
+<h3 id="Hazte_con_una_cuenta_Heroku">Hazte con una cuenta Heroku</h3>
+
+<p>Para empezar a usar Heroku necesitarás en primer lugar crear una cuenta:</p>
+
+<ul>
+ <li>Ve a <a href="https://www.heroku.com/">www.heroku.com</a> y haz click en el botón <strong>SIGN UP FOR FREE</strong>.</li>
+ <li>Introduce tus datos y pulsa a continuación <strong>CREATE FREE ACCOUNT</strong>. Se te pedirá que compruebes que has recibido un email de registro.</li>
+ <li>Haz click en el enlace de activación de la cuenta que aparece en el email de registro. Serás llevado de vuelta a tu cuenta en el navegador web.</li>
+ <li>Introduce tu contraseña y haz click en <strong>SET PASSWORD AND LOGIN</strong>.</li>
+ <li>Ya estarás contectado y serás llevado al tablón de Heroku (Heroku dashboard): <a href="https://dashboard.heroku.com/apps">https://dashboard.heroku.com/apps</a>.</li>
+</ul>
+
+<h3 id="Instala_el_cliente">Instala el cliente</h3>
+
+<p>Descarga e instala el cliente Heroku siguiendo estas <a href="https://devcenter.heroku.com/articles/getting-started-with-python#set-up">instructiones para Heroku</a>.</p>
+
+<p>Una vez instalado el cliente, ya podrás ejecutar comandos. Por ejemplo, para mostrar ayuda en el cliente:</p>
+
+<pre class="brush: bash notranslate">heroku help
+</pre>
+
+<h3 id="Crea_y_sube_el_sitio_web">Crea y sube el sitio web</h3>
+
+<p>Para crear la app ejecutamos el comando "create" en el directorio raíz de nuestro repositorio. Esta operación crea un git remoto ("puntero hacia el repositorio remoto") denominado <em>heroku</em> en nuestro entorno git local.</p>
+
+<pre class="brush: bash notranslate">heroku create</pre>
+
+<div class="note">
+<p><strong>Nota:</strong> Puedes nombrar el remoto, si lo deseas, especificando un valor después de "create". Si no, obtendrás un nombre aleatorio. Este nombre es el que se utiliza en la URL por defecto.</p>
+</div>
+
+<p>Podemos a continuación "empujar" (push) nuestra aplicación hacia el respositorio Heroku como se muestra abajo. Este proceso subirá la aplicación, la empaquetará en un dyno, ejecutará collestatic, y arrancará el sitio.</p>
+
+<pre class="brush: bash notranslate">git push heroku master</pre>
+
+<p>Si tenemos suerte, la app ya estará "corriendo" en el sitio, pero no estará funcionando correctamente ya que no hemos colocado las tablas que usa nuestra aplicación. Para hacer esto necesitamos utilizar el comando <code>heroku run</code> y arrancar un "<a href="https://devcenter.heroku.com/articles/deploying-python#one-off-dynos">one off dyno</a>" para realizar una operación de migración. Introduce el siguiente comando en el terminal:</p>
+
+<pre class="brush: bash notranslate">heroku run python manage.py migrate</pre>
+
+<p>Vamos a necesitar también poder añadir libros y autores, así que vamos a crear nuestro superusuario de administración, de nuevo utilizando un "one-off dyno":</p>
+
+<pre class="brush: bash notranslate">heroku run python manage.py createsuperuser</pre>
+
+<p>Una vez llevado a cabo ésto, podremos ver el sitio. Debería funcionar, aunque no tendrá aún ningún libro. Para abrir el navegador hacia el nuevo sitio web, usa el comando:</p>
+
+<pre class="brush: bash notranslate">heroku open</pre>
+
+<p>Crea algunos libros en el sitio de administración, y comprueba que el sitio se comporta tal y como esperas.</p>
+
+<h3 id="Gestionando_addons">Gestionando addons</h3>
+
+<p>Puedes revisar los add-ons de tu app usando el comando <code>heroku addons</code>. Se listarán todos los addons, su nivel de precio y estado.</p>
+
+<pre class="brush: bash notranslate">&gt;heroku addons
+
+Add-on                                     Plan       Price  State
+─────────────────────────────────────────  ─────────  ─────  ───────
+heroku-postgresql (postgresql-flat-26536)  hobby-dev  free   created
+ └─ as DATABASE</pre>
+
+<p>Aquí vemos que tenemos un único add-on, la base de datos postgres SQL. Es gratuito, y fue creado automáticamente cuando se creó la aplicación. Puedes abrir una página web en la que examinar con más detalle el add-on de la base de datos (o cualquier otro add-on) utilizando el siguiente comando:</p>
+
+<pre class="brush: bash notranslate">heroku addons:open heroku-postgresql
+</pre>
+
+<p>Otros comandos te permiten crear, destruir, subir o bajar de versión de los addons (con una sintaxis similar a la de abrir). Para más información, consulta <a href="https://devcenter.heroku.com/articles/managing-add-ons">Managing Add-ons</a> (Heroku docs).</p>
+
+<h3 id="Estableciendo_las_variables_de_configuración">Estableciendo las variables de configuración</h3>
+
+<p>Puedes revisar las variables de configuración para el sitio con el comando <code>heroku config</code>. Abajo puedes comprobar que solo tenemos una variable, <code>DATABASE_URL</code>, usada para configurar nuestra base de datos.</p>
+
+<pre class="brush: bash notranslate">&gt;heroku config
+
+=== locallibrary Config Vars
+DATABASE_URL: postgres://uzfnbcyxidzgrl:j2jkUFDF6OGGqxkgg7Hk3ilbZI@ec2-54-243-201-144.compute-1.amazonaws.com:5432/dbftm4qgh3kda3</pre>
+
+<p>Si recuerdas de la sección <a href="#Getting_your_website_ready_to_publish">Preparando tu sitio web para hacerlo público</a>, tenemos que establecer variables de entorno para <code>DJANGO_SECRET_KEY</code> y <code>DJANGO_DEBUG</code>. Vamos a hacerlo ahora.</p>
+
+<div class="note">
+<p><strong>Nota:</strong> La clave secreta tiene que ser verdaderamente secreta! Una forma de generar una nueva clave es crear un nuevo proyecto Django (<code>django-admin startproject nombredeproyecto</code>) y obtener la clave generada para tí de su archivo <strong>settings.py</strong>.</p>
+</div>
+
+<p>Establecemos el valor de la variable <code>DJANGO_SECRET_KEY</code> con el comando <code>config:set</code> (como se muestra abajo). Recuerda usar tu propia clave secreta!</p>
+
+<pre class="brush: bash notranslate">&gt;heroku config:set DJANGO_SECRET_KEY=eu09(ilk6@4sfdofb=b_2ht@vad*$ehh9-)3u_83+y%(+phh&amp;=
+
+Setting DJANGO_SECRET_KEY and restarting locallibrary... done, v7
+DJANGO_SECRET_KEY: eu09(ilk6@4sfdofb=b_2ht@vad*$ehh9-)3u_83+y%(+phh
+</pre>
+
+<p>De forma similar, establecemos <code>DJANGO_DEBUG</code>:</p>
+
+<pre class="brush: bash notranslate">&gt;heroku config:set <code>DJANGO_DEBUG=''
+
+Setting DJANGO_DEBUG and restarting locallibrary... done, v8</code></pre>
+
+<p>Si visitas ahora el sitio recibirás un error "Bad request", porque es <em>obligatorio</em> establecer <a href="https://docs.djangoproject.com/en/1.10/ref/settings/#allowed-hosts">ALLOWED_HOSTS</a> si tienes establecido <code>DEBUG=False</code> (como medida de seguridad). Abre <strong>/locallibrary/settings.py</strong> y cambia el valor de <code>ALLOWED_HOSTS</code> para incluir la url base de tu app (por ejemplo, 'locallibrary1234.herokuapp.com') y la URL que usas normalmente en tu servidor de desarrollo local.</p>
+
+<pre class="brush: python notranslate">ALLOWED_HOSTS = ['&lt;your app URL without the https:// prefix&gt;.herokuapp.com','127.0.0.1']
+# For example:
+# ALLOWED_HOSTS = ['fathomless-scrubland-30645.herokuapp.com','127.0.0.1']
+</pre>
+
+<p>A continuación guarda los cambios y consolídalos en tu repo Github y en Heroku.</p>
+
+<pre class="brush: bash notranslate">git add -A
+git commit -m 'Update ALLOWED_HOSTS with site and development server URL'
+git push origin master
+git push heroku master</pre>
+
+<div class="note">
+<p>Una vez completada la actualización del sitio en Heroku, introduce una URL que no exista (por ejemplo, <strong>/catalog/doesnotexist/</strong>). Antes se habría mostrado una página de depuración detallada, pero ahora deberías simplemente ver una página de "Not Found".</p>
+</div>
+
+<h3 id="Depuración">Depuración</h3>
+
+<p>El cliente Heroku proporciona algunas herramientas para la depuración:</p>
+
+<pre class="brush: bash notranslate">heroku logs  # Show current logs
+heroku logs --tail # Show current logs and keep updating with any new results
+heroku config:set DEBUG_COLLECTSTATIC=1 # Add additional logging for collectstatic (this tool is run automatically during a build)
+heroku ps   #Display dyno status
+</pre>
+
+<p>Si necesitas más información de la que te proporcionan estas herramientas, tendrás que investigar en <a href="https://docs.djangoproject.com/en/1.10/topics/logging/">Django Logging</a>.</p>
+
+<ul>
+</ul>
+
+<h2 id="Resumen">Resumen</h2>
+
+<p>Has llegado al final de este tutorial sobre la instalación de apps Django en producción, así como de la serie de tutoriales sobre el trabajo con Django. Esperamos que los hayas encontrado útiles. Puedes encontrar una versión completa del <a href="https://github.com/mdn/django-locallibrary-tutorial">código fuente en Github aquí</a>.<br>
+ <br>
+ El siguiente paso sería leer nuestros últimos artículos, y finalmente completar la evaluación.</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/">Deploying Django</a> (Django docs)
+
+  <ul>
+   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/checklist/">Deployment checklist</a> (Django docs)</li>
+   <li><a href="https://docs.djangoproject.com/en/1.10/howto/static-files/deployment/">Deploying static files</a> (Django docs)</li>
+   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/">How to deploy with WSGI</a> (Django docs)</li>
+   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/modwsgi/">How to use Django with Apache and mod_wsgi</a> (Django docs)</li>
+   <li><a href="https://docs.djangoproject.com/en/1.10/howto/deployment/wsgi/gunicorn/">How to use Django with Gunicorn</a> (Django docs)</li>
+  </ul>
+ </li>
+ <li>Heroku
+  <ul>
+   <li><a href="https://devcenter.heroku.com/articles/django-app-configuration">Configuring Django apps for Heroku</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/getting-started-with-python#introduction">Getting Started on Heroku with Django</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/django-assets">Django and Static Assets</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/python-concurrency-and-database-connections">Concurrency and Database Connections in Django</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/how-heroku-works">How Heroku works</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/dynos">Dynos and the Dyno Manager</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/config-vars">Configuration and Config Vars</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/limits">Limits</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/python-gunicorn">Deploying Python applications with Gunicorn</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/articles/deploying-python">Deploying Python and Django apps on Heroku</a> (Heroku docs)</li>
+   <li><a href="https://devcenter.heroku.com/search?q=django">Other Heroku Django docs</a></li>
+  </ul>
+ </li>
+ <li>Digital Ocean
+  <ul>
+   <li><a href="https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-uwsgi-and-nginx-on-ubuntu-16-04">How To Serve Django Applications with uWSGI and Nginx on Ubuntu 16.04</a></li>
+   <li><a href="https://www.digitalocean.com/community/tutorials?q=django">Other Digital Ocean Django community docs</a></li>
+  </ul>
+ </li>
+</ul>
+
+<p>{{PreviousMenuNext("Learn/Server-side/Django/Testing", "Learn/Server-side/Django/web_application_security", "Learn/Server-side/Django")}}</p>
+
+<h2 id="En_este_módulo">En este módulo</h2>
+
+<ul>
+ <li><a href="/es/docs/Learn/Server-side/Django/Introducción">Introducción a Django</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/development_environment">Configurando un entorno de desarrollo Django</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Tutorial_local_library_website">Tutorial de Django: El sito web de la Biblioteca Local</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/skeleton_website">Tutorial de Django Parte 2: Creando el esqueleto de un sitio web</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Models">Tutorial de Django Parte 3: Usando modelos</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Admin_site">Tutorial de Django Parte 4: Sitio de administración de Django</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Home_page">Tutorial de Django Parte 5: Creando nuestra página de inicio</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Generic_views">Tutorial de Django Parte 6: Listas genéricas y vistas de detalle</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Sessions">Tutorial de Django Parte 7: Framework de sesiones</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Authentication">Tutorial de Django Parte 8: Autenticación de usuarios y permisos</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Forms">Tutorial de Django Parte 9: Trabajando con formularios</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Testing">Tutorial de Django Parte 10: Probando una aplicación web de Django</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/Deployment">Tutorial de Django Parte 11: Poniendo Django en producción</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/web_application_security">Seguridad en aplicaciones web Django</a></li>
+ <li><a href="/es/docs/Learn/Server-side/Django/django_assessment_blog">DIY Django mini blog</a></li>
+</ul>