Yulup has the following USPs:
Please see this elaborate blog post of Atlassian for a good introduction to Continuous Integration, Delivery, and Deployment.
Table of Contents
First define Personas. They describe who is going to use your existing or new system/product. The Personas should comprise at least the customer/user groups, which are most likely to use your system. Keep them in focus when designing your system/product.
Some examples of Personas are:
Please do have a look at the corresponding chapter of the Quick Start Guide!
Table of ContentsUser Stories do describe what and why a functionality should be provided. But User Stories do not describe how a specific functionality is being implemented. That is where BDD Scenarios come into play.
Some examples of User Stories are:
Please do have a look at the corresponding chapter of the Quick Start Guide!
Table of ContentsUse BDD Scenarios to describe acceptance criteria and test cases. The BDD approach is well structured, simple and intuitive.
A BDD Scenario describes how a user experiences a particular functionality. Remember, the corresponding User Story depicts the reason why a certain functionality exists.
A required functionality can be implemented in many different ways. Therefore it is very important to specify as detailed as possible how a functionality should be implemented. This avoids misunderstandings as well.
The most convenient way is to directly write the BDD Scenarios in Yulup. But Yulup supports also the usage of third party systems for this task. In this case you can set the type of the BDD Scenario to external and store the URL of the BDD Scenario of the third party system.
Some examples of BDD Scenarios are:
A workflow is applied to each version of a BDD Scenario.
Please do have a look at the corresponding chapter of the Quick Start Guide!
Yulup currently supports the following SCM [Software Configuration Management] repositories:
Yulup currently supports two ways to connect a SCM repository with it:
Depending on the SCM you can set a webhook notifying Yulup when the SCM has been updated. Yulup currently supports webhooks of the following systems:
Please send an email if you would like Yulup to support another webhook, like for example Stash.
Set a webhook according to
https://developer.github.com/webhooks/creating/
pointing to https://www.yulup.com/scm-postreceive
Set a webhook according to
http://doc.gitlab.com/ee/web_hooks/web_hooks.html
pointing to https://www.yulup.com/scm-postreceive
Set a webhook according to
https://confluence.atlassian.com/display/BITBUCKET/Manage+Webhooks
https://confluence.atlassian.com/bitbucketserver/post-service-webhook-for-bitbucket-server-776640367.html
pointing to https://www.yulup.com/scm-postreceive
A Github-like webhook shell script can be downloaded at
https://github.com/wyona/gitolite-web-hook
whereas please see the following links about how to install and use it
If you cannot set a webhook, then you might want to configure the repository being pulled periodically.
There is a basic principle in agile testing: Every file change is associated with one or multiple tests. The tests can be different for the various environments (development, staging, production). For example when the Yanel README.txt
file is being changed, then various tests should be done, e.g.:
Let's assume, that all code files of your project are associated with tests. If now a developer is pushing changes - i.e. "storing an updated version of some files in the repository" - Yulup will conduct all automatic tests. And it will list all relevant tests that need to be done manually.
Of course things are more complicated behind the scenes. But as always the basic principle is very simple :-)
Start now associating tests with the source files inside your repository and learn how to do that by reading the following sections.
Table of Contents
Set Associations directly in Yulup instead of using meta files.
The easiest way to start to associate code files with tests needs no technical knowledge: After a code file has been added to or changed in the repository, it will be listed in Yulup within the 'Changes'. There you can connect it with any available test.
If you want to use meta files, please read on.
Files inside the code repository are associated with tests (automatic and manual) by creating meta files containing references accordingly.
Some examples are:
Looking at the examples, you will notice that each code file (e.g. UserRegistrationResource.java) is mapped onto a meta file by adding a suffix '_cd.xml' (e.g. UserRegistrationResource.java_cd.xml).
Instead of mapping each code file onto a meta file, you can also use patterns by using a meta map file. Here is an example inside the Yanel code repository:
As you can see, this way, all html files (e.g. testing-framework.html) are mapped onto the same meta file: If there is a 1-to-1 mapping as described above, then the patterns of the meta map won't be checked and applied.The meta files (and the meta map) can be located
Meta files can also be generated dynamically using java, which allows dynamic parameterisation, e.g.
To achieve this you have to implement the classcom.wyona.yanel.impl.resources.github.Meta
Table of Contents
A worker is a virtual server instance where your automatic tests will be executed within a safe environment.
See for example a junit test.
Table of ContentsFor each project you can configure various deployment environments. Yulup currently supports
When all tests of a change are successful, then you can create a new release or/and do an automatic deployment. This is done by adding a shell script 'create-release.sh' to the folder '.wyona-continuous/scripts', see for example Yanel.
If a project is based on multiple code repositories, then you can set a flag for one or more repositories in order to determine which shell script(s) should be triggered.
Challenging examples:
About Yulup
Made with in Zurich: