Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The workflow for this process is outlined below; consult the outlinks for details, tips, troubleshooting, etc.  It assumes you are familiar with Django, GitHub, and QA and Release Engineering practices.

Prerequisites to development

...

The UCB practice for Django Webapps is to have one (or perhaps more) Django Projects per institution.  Each of this is forked from the parent project, called cspace_django_project.

The "normal" workflow assumes you are the developer who will be creating the instituition's initial project and webapps, and that you are a CollectionSpace committer who can add repos under http://github.com/cspace-deployment.  However, such permissions are not required

If no Django project exists for your institution, or you need to make another one, the following steps will create such an institution level project in GitHub:   

...

Once an institutional project exists, you can check the code for it out from GitHub and do what you need to do on your local system. In general, we don't modify code directly on our VM deployments. The process of getting your code back into a GitHub repo and making deployments and releases is described further below.

  • From the command line: git clone myforkofinstituionsproject.git
  • Open this directory in PyCharm

...

  • Check out latest code (details?)
  • Modify
  • Test on your local system
  • git add, commit and
  • git commit -m
  • git push (where exactly?)

Deploying an institution project to a "Linux Server"

The initial deployment of Django projects on any server entailentails a number of "devops" activities. It is assumed that deployers reading this have an understanding of the process for deploying software on the target servers; here we assume that the deployment target is a "type IS&T VM" like those in use for the existing UCB CollectionSpace deployments. Your experience may differ.

Basically the procedure is as follows: 

  • Resolve dependencies (Apache (i.e. mod_wsgi), Python, Django, virtenv, SELinux, python packages)

...

  • Clone project to /usr/local/share/django

...

  • Modify Apache configuration to accomodate new project
  • Copy example config file(s) to config/ and customize per deployment (if any)

...

  • Restart Apache
  • Verify webapp function

The myriad practical details that need to be considered at UCB may be found here

Pushing your spiffy revised project to Dev or Production Server

Your project is already deployed and running (see the step above). You have made some wonderful fixes and improvements and you need to update the code on the server to the latest version:.

  • ssh in to the server
  • cd /usr/local/share/django/my_project
  • sudo git pull
  • update configuration file (if needed) ("sudo vi config/webapp.cfg")
  • sudo manage.py collectstatic

...

  • sudo service httpd graceful

Maintaining the parent CSpace Django Project

...