NREN approaches to software development

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.

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.

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.

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.

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.

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.

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.

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.