User Manual

Introduction

Getting Started

Specification

Personas

User Stories

BDD Scenarios

Supported Repositories

Connect to a Repository

Using a Webhook

Pulling Periodically

Agile Testing

Meta Files

Automatic Tests / Workers

Deployment Environments

Create a Release / Deployment

White Papers

Miscellaneous

Yulup has the following USPs:

• Yulup guides and supports you through the overall process of a software project: From gathering business requirements, to agile development, to continuous testing, and continuous deployment for operations. Just as DevOps bridges the gap between Development and Operations, Yulup bridges the gap between all major project stages.
• Testing starts already when the specification is being written. And then you re-use the specification for development and testing itself. This means less misunderstandings and much more efficiency.
• Let's be real, there are always a lot of manual tests. Because they are either still too complicated to automate, or it is not worth the effort. Hence Yulup allows to mix manual and automatic tests.
• Incremental testing, which means faster test results, scales better and code/test associations are documented.

Please see this elaborate blog post of Atlassian for a good introduction to Continuous Inte­gra­tion, Delivery, and Deployment.

Table of Contents

1. Create an account: www.yulup.com
(what you obviously already have done ;-)
2. Log in and create a project or have yourself invited to another project
3. Write the specification for your project (Personas, User Stories, and BDD Scenarios) directly in Yulup
4. Associate the project with your SCM repositories
5. Connect your SCM repositories using post-receive with Yulup
6. Create associations between code files and tests directly in Yulup or write meta files inside your SCM repositories containing references to the tests
7. Start updating your source files. And when pushing them, see how Yulup will take care of the rest :-)

For more extended instructions on how to get started please have a look at the Quick Start Guide!

Table of Contents

Table of Contents

Yulup currently supports the following SCM [Software Configuration Management] repositories:

• GitHub
• Other Git based cloud services
• Git (privately hosted/on premises)

Please send an email if you would like Yulup to support another SCM repository, like for example SVN.

Table of Contents

Yulup currently supports two ways to connect a SCM repository with it:

• The repository is notifying Yulup using a webhook
• Yulup is pulling the repository periodically

Table of Contents

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.:

• A spell checker should be applied
• A person should check whether the instructions actually make sense

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

Files inside the code repository are associated with tests (automatic and manual) by creating meta files containing references accordingly.

Some examples are:

• README.txt
• UserRegistrationResource.java
• YanelServlet.java

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:

• meta-map.xml

As you can see, this way, all html files (e.g. testing-framework.html) are mapped onto the same meta file:

• documentation.xml

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

• either inside the code repository itself, whereas by convention the meta files need to be located inside a directory called '.wyona-continuous', see for example YanelServlet.java
• or inside Yulup, see for example ConcurrentMergeScheduler.java

Meta files can also be generated dynamically using java, which allows dynamic parameterisation, e.g.

• junit.xml

To achieve this you have to implement the class com.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 Contents

For each project you can configure various deployment environments. Yulup currently supports

• Production/Live
• Staging
• Testing/Development

When all automatic tests are successful (or no automatic tests exist), then the testing environment gets updated automatically, such that manual tests can be performed, too. This is done by adding a shell script 'deploy-changes-on-testing.sh' to the folder '.wyona-continuous/scripts'.

Table of Contents

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:

• Additional Reverse Proxy configuration, e.g. new specific URLs will be introduced which are not within the existing URL space
• Replacement of backend implementation, e.g. data repository will be replaced

Table of Contents

• Continuous Development with Yulup

Table of Contents

• Why testing is challenging, illustrated by various examples
• Workshop on CIDD at the Swiss Federal Institute of Technology Zurich (ODP, PDF)
• Continuous Deployment, Drupal Style (Dcycle)
• Develop new feature - Sequence diagram
• Development and Deployment - Connections between involved parties

Table of Contents