-
Notifications
You must be signed in to change notification settings - Fork 2
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.
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.
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.
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.