Home | content | recommendations-uportal-and-git

Recommendations for uPortal and Git

Recently I was asked by a client to share some thoughts about working with Source Code Management (SCM) tools and uPortal, and specifically for best practices when it comes to updating the local portal project with newer Apereo sources.  Here's the essence of what I sent out.

There really is no substitute for Git in this area.  Git makes updating sources from Apereo simpler, faster, and dramatically safer/more predictable.  Moving your local uPortal source code to Git is really the only advice I can give you.  Here is a link to a page in the uPortal wiki that nicely covers working with Git + uPortal for precisely your situation.  Before writing this email, I even reviewed it a bit a made a few small edits for (I hope) increased clarity.

  - https://wiki.jasig.org/display/UPC/Git+Workflow+for+Vendor+Branching

On the bright side -- most any Git will work.  You can be successful with a locally-managed Git server, or by using a 3rd-party service like GitHub or Bitbucket.  Some schools expressly prohibit using a 3rd-party service, and must use a local Git server.  But if that's not your situation -- or if there's any ambiguity or wiggle room in your situation at all -- I highly recommend using a 3rd-party service.  Both are equally good and easy to work with, but we more often recommend BitBucket these days because it's cheaper.  (It's actually free for small teams.)

SIDE NOTE:  GitHub and BitBucket are both free for completely public repos, but you need a private repo for this purpose (of course).

Here's why I would choose a 3rd-party service...

  • They're insanely cheap or free;  using local resources for this purpose doesn't make fiscal sense
  • They maintain thousands of repos, and are world-leading experts at it;  a local sysadmin -- no matter how smart -- probably won't provide the same quality of service
  • They both provide a free, per-project issue tracker and wiki tool that are integrated nicely with the repo (references to tickets in commit messages become hyperlinks, etc.)
  • They both provide a very polished interface for viewing source files, commits, branches, and tags through a web browser (very handy)
  • If there's any chance that, in the future, you may want a hired gun -- at Unicon or elsewhere -- to review your setup or to make changes, providing that individual with access is likely going to be easier and quicker ($$) with a 3rd-party service

Regarding database passwords and other sensitive information -- I think most adopters go ahead and check these in to their private Git repos hosted by secure 3rd-party providers.  I believe it's a very reasonable thing to do.  As is evident by the term, a private repo is not accessible by anyone except those to whom you have expressly granted access.  Both GitHub and BitBucket use SSL to transfer any and all content within private repos (public repos too, for that matter).  Both services take security seriously and have loads of talented technologists configuring and monitoring their services, patching their servers with updated software, etc.  Arguably they may provide better security than a locally-hosted service.

But you don't have to check those passwords and sensitive bits into the project if you don't want to.  I believe (as I said) that most do check them in, but there are also many that don't.  With uPortal 4, it's pretty easy to factor all these items into the filers/ files (e.g. local.properties) and simply not check in the one(s) that contain your secrets.  You can optionally add these files to .gitignore, or just remember not to add them to a commit.

Using Git as your source repo, it becomes very, very easy (relatively speaking) to update patch releases, cherry-pick specific upstream (Apereo) bug fixes, or both.  Major and minor releases, however, are a different matter -- they call for a more hands-on approach.  Thankfully  these releases don't happen too often... only about every couple years.

Return to the blog listing page