Changes between Version 14 and Version 15 of SoftwareDevelopment/ProjectGuidelines

Timestamp:

06/20/17 12:34:10 (7 years ago)

Author:

Twan Goosen

Comment:

links to TravisCI

SoftwareDevelopment/ProjectGuidelines

@@ -39 +39 @@
 * Follow the '''conventions''' with respect to code layout, naming and project structure/organisation associated with the language and/or framework that you are using. There may not always be 'official' or uniform conventions, but Google has [https://github.com/google/styleguide style guides] for various languages (including [https://google.github.io/styleguide/javaguide.html Java], [https://google.github.io/styleguide/javascriptguide.xml Javascript], [https://google.github.io/styleguide/pyguide.html Python] and [https://google.github.io/styleguide/shell.xml Shell]) that generally provide good guidelines. Obviously, the most important thing is to use consistent style.
 * Provide '''automated tests''' (unit tests) for your source code. Various tools are available to measure the test coverage of your project. [http://cobertura.github.io/cobertura/ Cobertura] is an open-source solution for Java projects.
- * '''Run your tests''' every time you publish code or binaries. You can test locally on every build, or even better set up remote execution of your tests on a regular basis or triggered by commits/pushes  using a continuous integration solution that hooks into your versioning control system (such as [https://travis-ci.org Travis]).
+ * '''Run your tests''' every time you publish code or binaries. You can test locally on every build, or even better set up remote execution of your tests on a regular basis or triggered by commits/pushes  using a continuous integration solution that hooks into your versioning control system (such as [[TravisCI|Travis]]).
 * Try to '''get your code reviewed''', either by a colleague or someone else within the CLARIN community. Start the reviewing process early on, as it usually gets exponentially harder to make structural changes to your code base while it grows.
 * Make sure that there are no '''secrets''' such as passwords, or other '''environment specific values''' in your sources. Use external files (e.g. property files or XML documents) to provide these to your software and provide an example of such a file with your code.
@@ -48 +48 @@
 * Use  a 'modern' '''build automation tool''' and provide a build descriptor that does not rely on a highly specific context, i.e. make sure that your software can be built 'out of the box' if feasible, or provide instructions to prepare the environment for building the tool otherwise. [http://maven.apache.org/ Apache Maven] is used most commonly (for Java) within CLARIN. Other options are [https://en.wikipedia.org/wiki/Gradle Gradle] (for Java and several other languages) and [http://gruntjs.com/ Grunt] (for Javascript).
  * Make sure that all '''dependencies''' are available, either via public repositories or via additional repositories defined in your build descriptor.
-* Test your build regularly, ideally on a daily basis or with every commit/push, i.e. attempt to implement '''continuous integration'''. Generally applicable tools that can be used for this are, among others, [https://travis-ci.org Travis] and [https://jenkins.io/ Jenkins].
+* Test your build regularly, ideally on a daily basis or with every commit/push, i.e. attempt to implement '''continuous integration'''. Generally applicable tools that can be used for this are, among others, [[TravisCI|Travis]] and [https://jenkins.io/ Jenkins].
 * Consider distributing your application as a '''[https://docker.com/ Docker] image'''. The Docker website has [https://docs.docker.com/engine/getstarted/step_four/ instructions and more information].
 * Make '''all sources available''' that are needed to build your software. Use !GitHub for this purpose (you can join [https://github.com/clarin-eric CLARIN's organisation]).