GitHub for UH App Developers

The following is simply a set of recommended practices, not requirements. The benefits of these practices are explained herein.

Table of Contents

Background

At the 10/20/2015 UH App Developers meeting Dr Philip Johnson presented the topic "ITS: Please start using GitHub".  The request was not directed just at ITS, but at the entire UH IT community.  The rationale for the request was as follows:

  • The UH IT community is not a software development company.
  • The IT mission is not the development of patentable intellectual property.
  • There is compelling value and opportunity for us to create opportunities for sharing and collaboration given the substantial number of high tech developers at UH.
  • As software developers we should all be fluent with Git in this day and age.

Examples of collaborations can be considered for GitHub?

  • Sample programs for accessing UH services
  • UH branded WordPress themes and plugins
  • Scripts for setup, access, management of virtual servers

Why GitHub?

  • It's currently is the best cloud-based suite of tools for collaboratively developed source and documentation management.
  • It's free.
  • There's great documentation and it is supported by a very active community.
  • The vendor lock-in is minimal to nil.

Recommendation for the UH IT Community

  • Standardize on GitHub Organizations and public projects as our repository strategy so that we may more easily organize, share and discover each other's work.
  • Impose a hierarchical naming convention for UH GitHub organizations: root-campus-orgunit 
    • Root organization name for the top of the hierarchy
      • uhawaii
      • The root organization will be most beneficial if it not only describes these practices, but also includes references to our GitHub Organizations that are experimental or otherwise not following these standards.
    • Campus organization names include the root plus the standard campus prefix
      • Recommended campus prefixes:
        • uhawaii-system-
        • uhawaii-hawaii-
        • uhawaii-hilo-
        • uhawaii-manoa-
          uhawaii-honolulu-
        • uhawaii-kapiolani-
        • uhawaii-kauai-
        • uhawaii-leeward-
        • uhawaii-westoahu-
        • uhawaii-windward-
      • Participating campus project teams would follow the root and campus naming convention and determine for the remainder what best meets their needs.
      • Example system and campus organization names for GitHub: 
        • uhawaii-system-its-iam 
          • Identity and Access Management projects and sample code related to CAS, Grouper, Shib, etc.
        • uhawaii-manoa-ics-csdl
          • Department of Information and Computer Sciences, Collaborative Software Development Laboratory
        • uhawaii-honolulu-pcatt
          • Honolulu Community College, Pacific Center for Advanced Technology Training
    • Organization unit
      • This part is completely at the discretion of the campus project team.  Recommendation is to keep this part as flat as possible and not impose much more depth.  The above examples illustrate and 1 and 2 levels of additional depth.
  • Standardize on a single open source license to avoid complexity:

Security Considerations

  • Should I post projects not originally intended for GitHub.

    • Projects that were not originally intended for publication to GitHub need to be carefully reviewed prior to publishing them to ensure that credentials and any other sensitive information is not accidentally released.  You will have to decide if this additional work is the best use of your resources.
  • What is the best practice for dealing with passwords in github?

  • How would I clean up accidentally posted credentials?

What are other universities doing?

  • After about 30 minutes of hunting down Organizations established by other U's, there's scant evidence of any organized effort on the scale that we are proposing.

Additional work to be done

  • Draft recommendations for what to include in the documentation for each project.
  • Draft recommendations for git workflows so that we can more easily contribute to each other's projects.