| PT.WP.1 Platform Design and Deployment |
|
|---|---|
| Task 1: Iterative development process (M1-3) - EA; AIT |
Define and accomplish an iterative development process based on best practices of agile development and decentralised work, addressing the issues of release management, testing, documentation, and deployment. (MS22) |
The purpose of the plan is to keep things moving, while attempting to ensure integration will work and the code quality is high. If the infrastructure is getting in your way, get in touch with the Technical Coordinator.
This plan is based on a central repository where we all work together. Of course in some cases, e.g. if the work involves forking an existing project, this may not be appropriate. If so, please let me know so I can track the code and ensure it is integrated into the build and sustained by the Open Planets Foundation as necessary.
Keeping In Touch
The main code-oriented communication will be via github.com and the OPF Labs resources. See Getting started for details.
Developer Workshops
The first developer workshop has been announced here
, with details here. Please keep an eye on the SCAPE and/or OPF web sites for future announcements. More information will be added under the Events page.
People in SCAPE on twitter include:
- @SCAPEproject and see also #SCAPEProject.
- @anjacks0n
Mailing Lists
See http://list.scape-project.eu/cgi-bin/mailman/listinfo/techie
Default To Open
All code will default to open source and be publicly available by default. If particular pieces of code are found to have dependencies or legal restrictions inconsistent with this approach, they will be moved elsewhere.
Code & Repository Management
We will start with a single shared repository. All developers will have write access. Code will be arranged by work package.
Any pull requests will be fielded by the Technical Coordinator.
This will be reviewed at regular intervals. As the functional requirements become clearer, the code may be refactored along functional lines rather than by work package.As the code stabilises and matures, we may switch to a more tightly managed system where the core repo has limited commit access and larger modifications are managed via pull requests. Similarly, if a single shared repository is not working well, we can split the code into sub-repositories as required.
Proposal for the package identifier for SCAPE code:
- eu.scape_project
Having to use underscores is a little awkward, but it's probably the only appropriate domain.
Issue Tracking
The GitHub SCAPE shared repository enables an Issues tracking page for specifying and tracking bugs, issues and other actions that need to be performed that relate to the code. See Connecting GitHub Issues lists to Eclipse for details of how to track these issues in Eclipse.
Licensing
The default code licence for SCAPE is Apache 2.0. Get in touch with the Technical Coordinator if that causes a problem, e.g. when extending an existing project under the GPL.
Build Management
We will initially target Java 6, and Java 7 will be evaluated as soon as possible.
We will drive the main build with Maven 2. This is well supported in all major IDEs without managing IDE-specific config files.
Developer IDEs are Eclipse, NetBeans, IntelliJ and good old CLI.
For information on testing and continuous integration, see Bamboo.
plan=SP-SITE&groupByPeriod=DAY&dateFilter=ALL&isConfigured=true&refresh=false
Project Integration Plan
In concert with the platform developers, the TC will facilitate the agreement of interfaces and data types that are shared between work packages. Where possible, this will be based on existing concepts from Planets related work (particularly JHOVE2). For example, to cope with compound entities, we should probably adopt JHOVE2's Source and Input model instead of using plain Files.
Publishing our outputs via Maven
Maven artefacts will be pushed to the central Maven repo via Sonatype, if appropriate. See this ticket for details.
As well as publishing our own artefacts so that they can be re-used, we will also pursue the possibility of getting other related projects to publish there artefacts through Sonatype, and indeed help them do so. This will encourage code reuse and help ensure the network of software dependencies we need will be preserved over time. If we cannot publish JARs directly, we can also use Sonatype to upload third-party JARs.
Code Analysis
Dynamic and static code analysis is automatically done when pushing code to GitHub and accessible at:
On projects with many sub-projects, such as SCAPE, component drill-down is accessible in the Components menu:
http://ca.keep.pt/components/index/342
Minimum requirements for code quality will be later defined, current values are set on:
| Metric | Threshold |
|---|---|
| Blocker violations | Cannot be bigger than 0 |
| Critical violations | Should not be bigger than 0 |
| Unit test code coverage | Should not be less than 80% Cannot be less than 10% |
| Density of public documented API | Should not be less than 80% Cannot be less than 20% |
Sonar metric definitions are available at http://docs.codehaus.org/display/SONAR/Metric+definitions