v2.0.0-rc1 Release Notes

This release is fully backwards-incompatible with 1.x because there's been a massive overhaul of its internals. The internals are now much easier to work with and I expect that there will be a lower threshold to contribute.

The public API of v2.0 is simpler. For example, have a look at the README as an example of the new API.

I recommend you start using the new version today! It's well worth the time investment; this is the version that albacore is going forward with.

Changes: Improvements

The new version is built around the fact that NuGet has become the de-facto standard of managing your .Net dependencies. It will run NuGet.exe transparently on both Windows and Mono. We develop both on Mac and on Windows at Intelliplan, so the code has been tested for over half a year already.

One improvement that you will experience, switching to the new version, is how easy it becomes to bootstrap builds of nugets; all you have to do is to give an enumerable of file paths to the #files property:

nugets_pack :nugets => ['build/pkg', :versioning, :build] do |p|
  # FileList looks at the file system, returning an enumerable:
  p.files   = FileList['src/**/*.{csproj,fsproj,nuspec}'].
    exclude(/Tests/)
  p.out     = 'build/pkg'
  p.exe     = 'buildsupport/NuGet.exe'
  p.with_metadata do |m|
    m.description = 'A cool nuget'
    m.authors = 'Henrik'
    m.version = ENV['NUGET_VERSION']
  end
end

Given that you have the normal workflow of adding a new project to your src folder and inside the sln that you work with, that project will then be made a nuget of. Zero friction. Attaching the teamcity extension will ensure that your new nuget is recognized by TeamCity, too, meaning that you'll have a bootstrapped NuGet server very very quickly: require 'albacore/ext/teamcity'.

Other improvements include unified logging and a better object model behind the scenes. Also, everything is unit-tested, at 322 test cases at the moment, and counting.

Many improvements have been made to the nuget handling, to make it easier. In the end, creating nugets should be as easy as writing Gem::Tasks.new or in this case NuGet::Tasks.new, and then rake release when you want to commit, tag and push a new nuget to NuGet.org. Albacore should support both the open source workflow and the proprietary-code workflow.

Albacore has now got a very simple publish-subscribe pattern implemented which is being used to publish when artifacts are created, at the moment, but can publish any sort of event.

More changes and improvements in list-form

• All public APIs are now documented, so go read the code!.
• The very few actual task-types now reside in their own folder. The idea is to have more integrations done over the pub-sub facility as well as extensions.
• Useful tools that you run one-off are in tools, and will be possible to use in an albacore binary a Minor release, or two, from now.
• It is now possible to control output much more closely, making it easier to have albacore be as transparent as possible in your build process.
• When you want to log from your own Rakefile you can now do things like:

require 'albacore'
require 'albacore/logging'

include ::Albacore::Logging

task :my_task do
  trace { "hello world" }
  system 'echo', 'goodbye'
end

• Path handling is always a mess when building .Net/Mono applications cross platform; use Paths for great good.
• If you need a class to manipulate xxproj-files with, have a loop at the Project model.
• If you find yourself writing something to wrap an invocation of an executable, as a class, you can write something like this:

require 'set'
require 'albacore/cross_platform_cmd'

class TxSrv
  include ::Albacore::CrossPlatformCmd # includes e.g. #system, #mono_command
  def initialize
    @parameters = []
    @executable = 'buildsupport/TransactionServer_IntegrationTests.exe'
    # makes sure mono is there if running on linux:
    mono_command
  end
  def execute
    system @executable, *(@parameters.to_a)
  end
end

class RunTests
  include ::Albacore::CrossPlatformCmd # includes e.g. #system, #mono_command
  def execute
    exe = FileList['src/packages/machine.specifications.*/tools/mspec.clr4.exe'].first
    dll = 'src/ProjA/bin/Debug/ProjA.dll'
    system exe, dll
  end
end

task :it_tests do
  t = Thread.new do
    TxSrv.new.execute
  end
  # run tests here
  RunTests.new.execute
ensure
  t.kill
end

As you can see, there have been many changes and improvements aiming to make albacore a much nicer library to include whenever you have a .Net project that needs building and packaging.

Other changes, contrasted with master branch

The improvements aside, there are structural changes to the rewrite, too:

• No longer do we have a custom "task" - that is a custom DSL method, per 'application', unless that application really supports CLR development and is needed 'normally'. Instead we have "task types"; these show up in the DSL, that is they can be used in the Rakefile.
• All task-types are now deferred until they are required to execute. Nothing but file globs and similar things run until the task is required to have executed. Previously this has been almost on a per-task basis.
• The output task hasn't been coded yet because I couldn't understand why a simple Dir.glob( ... ).each { |file| cp file, target } didn't cut it.
• It's no longer possible to globally configure albacore with settings, simply because the task-types are more powerful this time around.
• Task-types now do simple assignment to their lambda-parameters, rather than method invocations -- except when deviating from the default, in which case the deviation is a method call (like Build::Config.gen_symbols), or when giving parameters that are best represented with a method call, such as NugetsPack::Config.attributes.

The road ahead

A little about where Albacore is headed.

Configuration and VaryByParam

In the README for this release, I have documented one feature that has been rebuilt by albacore consumers many times over; building with multiple frameworks -- e.g. constructing a build task-type and having it run once with .Net 3.5 and then a second time with .Net 4.5, executing the full task-graph every time.

Having a configuration that does 'vary by param' would make this type of build-per-parameter-combination much easier to perform.

Representing the tasks as a graph

In v3.0 I want to have refactored Albacore.create_task and all task-types in the DSL to construct an immutable graph of things to build. Only after constructing the immutable snapshot (specification) does the build commence by starting to call the tasks' #execute.

This would make the build much more declarative and make interop with project like repobuild easier to program.

Besides, it would allow a much higher degree of modification by extensions, by letting each task (created through a task-type-method in the DSL) carry with it its Config and description and list of dependencies. This graph of tasks could then be fed through a pipeline where each extension can inspect and possible output a new/changed graph, should it want. Since the graph is directed, acyclic, the vary-by-param task could then be implemented simply as a task that takes its child trees (child tasks) and duplicates them, having all child tasks take properties of the Config of the Vary-By-Param task as DependentVariables.

Improving deployment

In v3.0 I want to have a deployment example for Linux and mono with proper versioning and artifact management. Simply put; everyone needs to deploy their systems, and if the build system can help you or recommend you how to do that, it's a gain. Work items such as #54 come to mind, something that should dovetail nicely with a v3.0 release of albacore.

Improving testing

For .Net developers in general, starved half to death of good testing tools (albeit excellent tooling for unit-tests in particular, not much after that), having a build system that makes it easier to test code, could be invaluable. Just as nugets_pack allows you to bootstrap your nugets very quickly, integration with for example tsung or suave would make it much easier to test your web code.

The aim of albacore, hence, isn't to force these tools on you, but rather to provide a runtime that can be used on a CI-server that keep the tools in check, configuring their runs, running and monitoring the processes and then collecting their results.

Conclusion

I'm really happy to have gotten this release out of the door, so test it. Around new-year I plan on doing the RTM v2.0 release unless something comes up.

Happy coding! Henrik Feldt