PureKrome/gist:f03131e8778ced0b8209

## gistfile1.txt
Preceived Problem
^^^^^^^^^^^^^^^^^

Currently, when we try to deploy an ASP.NET website to a Host Server, it's a tricky and complex set of tasks. It's even more frustrating when this is handled by a Continuous Integration service.

It feels like the full build / package / deploy *lifecycle* is currently a hap-hazard mix of band-aid solutions to try and solve this mission critical problem.

Quote @FrankR:
"Its the whole process of looking at code in your IDE, to compiling, composing components, ILMerge, minification, CSS parsing, Installshielding, web deployment packaging, password/security bundling, test running, switching prod server offline, clearing logged in accounts, copying files, turning server back on, logging. Phew."

What we would love - A clean and simple lifecycle story
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Inspired by the changes in vNext with respect to the new project (files that demonstrate minimalism and simplification), we would love to see a new build file story where it's easy to handle the __full build cycle from the command line__ instead of having Visual Studio hiding much of the magic, hooks and teaks.


Use Cases
^^^^^^^^^
Given a single MVC Website, build it and deploy.
1. Compile the site to a destination directory => C:\Temp\Build<Name>_<Date>
2. Deploy the site to a Host (eg. azure or iis somewhere).

Given a single MVC Website, build it, transform, package and budle.
1. Compile the site to a destination directory => C:\Temp\Build<Name>_<Date>
2. Do transforms on any config files (remember, this might be .json files with the vNext bits).
3. Deploy the site to a Host (eg. azure or iis somewhere).

Given a single MVC WebSite, build it, minify + bundle, package then deploy.
1. Compile MVC site to a destination directory => eg. C:\Temp\Build\<Name>_<Date>
2. Do transforms on any config files.
3. Node.exe to minify/bundle the JS/CSS @ C:\Temp\Build\<Name>_<Date>
4. Zip up website into a zip.
5. Take website _server_ offline (eg. Update load balancing to stop sending traffic to that server or an Offline.htm file)
6. Copy zip up to IIS, delete all existing website contents and then unzip.
7. Turn website back online (revert LB or delete Offline.htm).


What about GIT DEPLOYMENT from MAWS?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:heart: Git deployment from MAWS! Would :heart: to do custom steps like
a) Transforms
b) minify/bundle
c) offline the target server

(not sure how much KUDU does this)

Final Notes
^^^^^^^^^^^
1. Use existing technologies instead of re-inventing the wheel (eg powershell?)
2. Stop using MSBuild.


Contributors:
- PK (@PureKrome)
- YOU PLEASE!
	Preceived Problem
	^^^^^^^^^^^^^^^^^

	Currently, when we try to deploy an ASP.NET website to a Host Server, it's a tricky and complex set of tasks. It's even more frustrating when this is handled by a Continuous Integration service.

	It feels like the full build / package / deploy lifecycle is currently a hap-hazard mix of band-aid solutions to try and solve this mission critical problem.

	Quote @FrankR:
	"Its the whole process of looking at code in your IDE, to compiling, composing components, ILMerge, minification, CSS parsing, Installshielding, web deployment packaging, password/security bundling, test running, switching prod server offline, clearing logged in accounts, copying files, turning server back on, logging. Phew."

	What we would love - A clean and simple lifecycle story
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

	Inspired by the changes in vNext with respect to the new project (files that demonstrate minimalism and simplification), we would love to see a new build file story where it's easy to handle the __full build cycle from the command line__ instead of having Visual Studio hiding much of the magic, hooks and teaks.


	Use Cases
	^^^^^^^^^
	Given a single MVC Website, build it and deploy.
	1. Compile the site to a destination directory => C:\Temp\Build<Name>_<Date>
	2. Deploy the site to a Host (eg. azure or iis somewhere).

	Given a single MVC Website, build it, transform, package and budle.
	1. Compile the site to a destination directory => C:\Temp\Build<Name>_<Date>
	2. Do transforms on any config files (remember, this might be .json files with the vNext bits).
	3. Deploy the site to a Host (eg. azure or iis somewhere).

	Given a single MVC WebSite, build it, minify + bundle, package then deploy.
	1. Compile MVC site to a destination directory => eg. C:\Temp\Build\<Name>_<Date>
	2. Do transforms on any config files.
	3. Node.exe to minify/bundle the JS/CSS @ C:\Temp\Build\<Name>_<Date>
	4. Zip up website into a zip.
	5. Take website _server_ offline (eg. Update load balancing to stop sending traffic to that server or an Offline.htm file)
	6. Copy zip up to IIS, delete all existing website contents and then unzip.
	7. Turn website back online (revert LB or delete Offline.htm).


	What about GIT DEPLOYMENT from MAWS?
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	:heart: Git deployment from MAWS! Would :heart: to do custom steps like
	a) Transforms
	b) minify/bundle
	c) offline the target server

	(not sure how much KUDU does this)

	Final Notes
	^^^^^^^^^^^
	1. Use existing technologies instead of re-inventing the wheel (eg powershell?)
	2. Stop using MSBuild.


	Contributors:
	- PK (@PureKrome)
	- YOU PLEASE!