AnFake Convention

NOTE. Convention described below IS NOT a requirement. If you follow it then AnFake will be able to evaluate the most parameters automatically otherwise you will need to provide values explicitly.

Source Control Structure

AnFake supposes you TFS source control organized with a following way:

$/TeamProject
    /BuildProcessTemplates
        /CustomActivities
    /ProductA
        /ModuleA
            /dev
            /releases
                /1.0.0
        /ModuleB
            /dev
    /ProductB
        /dev
        /features
            /new-feature
        /releases
            /1.0.0
            /2.0.0
$/Infrastructure
    /NuGet
        /2.8
    /Settings
        /current

"Infrastructure/Settings" intended for configuration/settings files related to whole build infrastructure but not particular product/module. The examples of infrastructure settings are: URL of internal NuGet package server; NuGet access key for package publishing; DB connection string for report publishing and so on.

Local Structure

Products and modules are supposed to be checked out locally as:

C:\Projects
    \ModuleA
        \dev
        \1.0.0
    \ProductB
        \dev
        \new-feature

As you can see there is no local "releases" and "features" sub-folders. This is because developer normally works with a limited set of products, modules, branches and therefore there is no reason to repeat locally entire complex structure of source control.

Take a closer look at local "C:\Projects\ModuleA\dev":

\dev
    \.NuGet
        NuGet.exe
        packages.config
        ...
    \ModuleA.Component1
        ModuleA.Component1.csproj
        ...
    \packages
        \AnFake.1.0.4         
    .workspace
    AnFake.settings.json
    build.fsx
    ModuleA.sln

Really, it is assembled from several source control folders with a help of TFS mappings:

$/TeamProject/ProductA/ModuleA/dev: \Projects\ModuleA\dev
$/Infrastructure/Settings/current/AnFake.settings.json: \Projects\ModuleA\dev\AnFake.settings.json
$/Infrastructure/NuGet/2.8: \Projects\ModuleA\dev\.NuGet

These mappings are stored in ".workspace" file (but in a bit more convenient way) and AnFake can create/update TFS workspace using such file.

The "AnFake.settings.json": is an infrastructure settings file as described above and build.fsx is a build definition script on F# (or build.csx on C#).

NuGet doesn't matter for AnFake functionality and provided here just for example.

FAQs

Q. Why special location for infrastructure settings?

A. Let you have product with a 5 components and each component has at least 2 branches. If you hard-coded, for example, connection string directly in build.fsx then you have 10 occurrences of this string in 10 different locations.

Now lets imagine you have migrated DB to another host server then you need to update connection string in 10 places...

With AnFake approach you should update just a single file AnFake.settings.json and all following builds will use new DB server.