Fork me on GitHub

Concepts

This page describes the concepts how Appccelerate is being built.

Multi Repository

Every component that is released independently has its own dedicated repository.

This allows to advance the different components independently from all others.

As a consequence, every component has its own version number. See versioning for more information.

When working with several repositories, and especially when working with repositories with dependencies to other repositories, it is best to clone them into a single folder.

When you clone all Appccelerate repositories, it should look like this:

With this setup, you can use the Appccelerate PowerShell commandlets.

Branching Strategy

In the main repositories of Appccelerate - the ones at http://github.com/appccelerate, there is only a master branch. Everything is committed (or merged in from pull requests) to this branch.

In forked repositories, you are free to use whatever branch you like - typically a branch named after the feature you are implementing. Using a branch per feature enables a pull request per feature. But if you only want to contribute something small, be free to implement it on the master branch of your fork.

Your pull requests should be opened against the master branch of the Appccelerate main repository. See pull requests for more information on how we integrate your pull request. See versioning for more information on how versioning with only a master branch works in Appccelerate.

Versioning

Appccelerate uses the Appccelerate GitVersion Task to version its assemblies.

This has the advantage that the assemblies can be versioned everywhere - on the build server or on your machine. This gives you the flexibility to try things out locally on your machine.

Every Appccelerate repository has its own version. This has the advantage of being very flexible, but the disadvantage that is very hard to see, which components of which version can work together. Therefore, the .nuspec file of every production assembly should state the exact version of every Appccelerate nuget package dependency.

When you open a pull request, the Appccelerate build server creates a nuget package for your changes and pushes it to the Appccelerate feed on MyGet (see Pull Requests). The build server will use a pre-release version for this package. The pre release part looks like -commit<hash>, with <hash> equal to the first 8 digits of the commit hash of the merge commit created for merging your changes into the master branch of the main repository.

StyleCop, Build Tasks, Tests and Specifications

We built Appccelerate to support us in our commercial projects. Therefore, we value quality, easy maintainability and flexibility a lot. But we don't like to put energy into thinking about basic stuff like readability, keeping consistency and so on. That's why we use tools to check everything possible.

StyleCop

StyleCop checks for violations of our code style guidelines. Together with Resharper, you get real time feedback while coding. When building in release configuration, StyleCop violations break the build.

There exist different rule sets for production, unit test and specification assemblies. See the Settings.stylecop in the project folders for details.

To keep the Stylecop settings consistent throughout all repositories, they are included using the Development Packages.

Build Tasks

When compiling with release configuration, several MS build tasks are run.

StyleCop

Checks for coding style guideline violations (see StyleCop).

Check Hint Path

Checks that all hint paths references in the project file are valid (no references to bin for example). See check hint path task for more information.

Check Nuget Dependencies

Checks that the versions of referenced assemblies and the version patterns specified in the .nuspec file match. See check nuget dependencies task for more information.

Appccelerate Development Nuget Packages

Appccelerate uses nuget packages to setup and update the build infrastructure:

There exist different packages per kind of assembly:

Nuget Packages

All Appccelerate components are released using Nuget, every component as a single package.

Nuget packages are built from .nuspec files. The Appccelerate build server recursively looks for .nuspec files and creates nuget packages for them. These packages are then published to the Appccelerate feed on MyGet (https://www.myget.org/F/appccelerate/)

You can create Nuget packages locally for trials using the CreateLocalNugetPackages commandlet.

GitHub, Pull Requests and MyGet feed

You open a pull request to contribute your changes to the main Appccelerate repository.

Whenever a pull request is opened or new commits are added, the Appccelerate build server tries to

In case of success, you can use the pre-release package to verify your changes in your project.

In case of failure, click on the details link in the merge information on the pull request page. You are navigated to the failing run on the build server. See the build log for details what went wrong.

You can log in as a guest.

If you cannot fix the problem on your own, comment on the pull request about what you tried. We'll try to help you.

PowerShell commandlets

The Appccelerate PowerShell commandlets simplify working with multiple repositories. These commandlets provide functionality regarding:

See PowerShell commandlets for details.