manojlds / ydeliver Goto Github PK

something like this

pre-build: { Get-Host | Out-File build.host.info }

Currently, the only way to do database migrations is to have a task that invokes one of the many 3rd party programs (i.e dbdeploy etc.) to run the migrations against the database.

Instead, there could be pure posh tasks that do the migrations. Could even fork and use this - https://github.com/evenkiel/pomm

Nice to have...

tests:
unit:
path-expression: src\foo*.Tests.csproj
integration:
path-expression: foo.src\IntTests.csproj

Allow injectable pattern to find test csproj files.
Add logic to find nunit-console

If project is already managing it's own dependencies plugin installation should inspect the project to see if dependency constraint is already met.

This would be nice so we don't need VS installed on the machine building the code.

got ydeliver through nuget, in a x86 machine. and when trying to run the build, it was failing with

No .NET Framework installation directory found at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\

it took me a while to find, it was hard-coded in the conventions to be "4.0x64".

Faced similar issues with locating the solution file.

It would be good if these conventions can be mentioned from build.ps1 file.

There are 3 types of variables passed around parameters, globals, and overrides. Can conventions help identify which variable is what kind?

Also a modelling diagram of environments/roles/applications/tasks will help. What is contained in what, and what is configured in which yml file.

build.yml should only need to reference support code like the installation scripts and other deploy time dependencies. Project files will be included based on the OutputPath spec.

http://develoq.net/2011/create-an-output-folder-each-project-in-your-solution-like-_publishedwebsites-for-web-applications/

Acceptance Critiera:

A project with multiple projects will be segregated in the package dir. So a solution with a console app, web app, and a service will have separate directories in build\package for each of these without having to define packageContents in build.yml