Versions Compared

Key

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

...

This document describes the soup-to-nuts engineering process for creating and maintaining a "cspace_django_project" Project for your institution.  The This process is the culmination of some months of experimentation and development at UCB, and what you see here is really the tip of the iceberg. The many details of how this whole process works process came about, its motivations, and its justification, are here.

The Below, however, please find the essential 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.

...

At UCB, development of Django webapps is done using Pycharm. Therefore, your first step in any case is to install Pycharm on your development system. (Unless of course all you are doing is deploying existing code from GitHub, in which case skip ahead to the deployment section.)

...

The UCB practice for Django Webapps is to have one (or perhaps more) Django Projects per institution.  Each of these is forked from the parent project, called cspace_django_project and is maintained as a separate entity.

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

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:   

...