Versions Compared

Key

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

As part of its work, SIG Greenhouse has asked NREN and NREN customers to provide input into the approaches they currently have to internal software development.  This includes everything from policies and strategies associated with software development to informal approaches used by development teams.  The results of these discussions are shown below.  The Greenhouse SIG is interested in understanding why and when NRENs choose to code and what drives approaches to (not)coding.

Should we look to develop something akin to the US government Source Code Policy?

 

AreaCANARIE - IdP Installer exampleHEAnet / JAGGER exampleUmea exampleJisc ExampleGÉANT Example
Policy

NREN environment is geared toward 'Don't expose us to risk' and 'don't leave people with false expectations' as a prime driver. Our work on the IdP-Installer was process driven to try and figure out what we wanted to do: - define requirements - assess the options and rank them with a recommendation - execute and evaluate as you go In our requirements phase we wanted to be capable of supporting what we chose -- i.e. 'sustainable'. It was not spelled out exactly this way in the requirements but the qualities of sustainability were there -- how easy will it be to support what we built? Is what we intend to build (the installer) meet what platforms are in the field? How do you maintain it? The build-or-buy decision was formed at that time and we originally did 'let's buy this' and unfortunately that was a mismatch and delayed us 3-6 months. We then opted for a full control model which was more work, but allowed for a much higher degree of control and therefor ability to execute.

 

No existing policyNo existing policyPolicy used to exist: http://www.webarchive.org.uk/wayback/archive/20140614222330/http://www.jisc.ac.uk/fundingopportunities/opensourcepolicy.aspx - not currently active. 
IPR / Licensing

Our work on the IdP-Installer is joint with SWAMID and started with GPLv3 and so we stayed with that approach. See links in the greenhouse wiki for our assessment of all the software licenses of the subcomponents we marshal together. This plays well into the 'we built this to be an approach of N+1 federations' using the tool and extending it. What we have really asked from anyone seriously interested is that they identify an internal champion.

  If no one asks for anything special we use Apache License, Version 2.0 for all our software packages.  
Support

Support of a federation specific configuration is key. Do the creators bear the support of federation X not working on platform Y at time Z? Not unless it's their federation. For instance, inCommon has a 'build' of the IdP-Installer, but this effort was done by OARNet, not inCommon. So if there's something awry with the build specific to that, OARNet is the goto support.

We maintain backward compatibility
Frequent updates with small changes
   
Packaging

chose NOT to package in OS specifics since we are cross platform and this is more of a dev-ops style way of managing things. It's not a managed service, just a managed installation at which time we hand over the keys to you to manage the host post installation. We do have some documentation (crude) on dev style when working on the code base. Our code is BASH and is inspired by puppet, ansible, salt, and chef but without the dependancies. Did we have to rework things? A little. Is this sustainable? Yes. It is very approachable by any first level system admin that can observe what's going on in a shell script.

  If we need to package anything we use Docker or Vagrant.  
Language / frameworkshellscriptPHP - minimum version: 5.4.x / CodeIgniter 3.x

First our main language is Python. We use JavaScript where we have to but no other language.

 

So far if we need to set up a web service we use built-in servers like cheerypy/flask/.. instead of depending on something like an Apache server.

  
Additional libraries Doctrine-ORM , Jquery, Zurb Foundation   
Versioning / hosting

We use semantic versioning ( http://semver.org/ ) as our pattern followed by -<federation-short-name> Attached is our approach to code stewardship. Inspired by a reference we came across but also by Janusz @ HEANET with jagger.

Hosted on github

  workflow from dev to stable:
  *) very early dev stage - https://github.com/janul/Jagger
  *) official dev - https://github.com/Edugate/Jagger/tree/develop
  *) stable - https://github.com/Edugate/Jagger/tree/1.x-stable

All our software as soon as it’s passed version 0.1 can be found on github. On github we bind a couple of services to each project: - Landscape (https://docs.landscape.io/index.html) - ReadTheDocs (https://readthedocs.org) - Travis CI (https://travis-ci.org)

We do frequent releases of new versions using the classic major.minor[.build[.revision]] version format. We aim for small incremental updates.

  
Tools / testing

I've started using codeclimate.com and codacy.com. Shell scripting is not as 'exciting' as things like PHP, Java, or Python and hence code styles are not as predominant. We are getting better at some code style guides like: http://www.kfirlavi.com/blog/2012/11/14/defensive-bash-programming And https://google.github.io/styleguide/shell.xml We are by no means perfect and haven't come across a site like codeclimate/codacy that can validate/score our code base.

when started writing Jagger there was nearly imposible to implement php-unit tests for Codeigniter (1.7) - but now the situation is much better so the plan is set unit tests for the most important functionalities

Not officially doing test driven development but we aim to have as close to complete test coverage as possible.

Landscape for code quality/readability Travis CI to verify that our code works on the different Python versions we aim to support ReadTheDocs to always have a publicly available copy of the latest documentation.