Posts tagged autodeploy

AutoDeploy.NET to GitHub

Jul 20th

Posted by Eric Polerecky in ASP.NET

No comments

First; When I pushed to GitHub I decided to rename the project to AutoDeploy.NET.

In the hopes of keeping my sanity and in the context of working in an organization that strictly follows a 50+ page “release management handbook” I started working on AutoDeploy.NET; a deployment automation tool.

As with all my personal projects I took an academic approach to the design and implementation. Instead of building an entire application I created a class library (dll) and used a few 3rd party libraries that I was either unfamiliar.

Class Library

My thought here is that by just creating the class library I would have a chance to create a fluent interface and if I did that well enough, creating a UI would be a trivial task. I have not hit a brick wall with this decision but messaging and logging might soon bite me in the…end.

Sharp SVN

SharpSvn is a binding of the Subversion Client API for .Net 2.0 applications contained within a set of xcopy-deployable dll’s

Working with source control should be part of every deployment, build process, or continuous integration. I use SVN for my source control and so did organization. As I, along with what seems like the rest of the world, move to Git I might find time to write a Git service for AutoDeploy.NET

Html Agility Pack

The Html Agility Pack is an agile HTML parser that builds a read/write DOM and supports plain XPATH or XSLT (you actually don’t HAVE to understand XPATH nor XSLT to use it, don’t worry…). It is a .NET code library that allows you to parse "out of the web" HTML files. The parser is very tolerant with "real world" malformed HTML. The object model is very similar to what proposes System.Xml, but for HTML documents (or streams).

Instead of using Sharp SVN or simple the .NET webclient I used the agility pack to parse the html that is returned when browsing a SVN repo. This is done to monitor the repo for new tags and kick off deployments based on the tag convention x.x.x.

The use is purely academic and limited in scope. It could easily be removed in order to cut-down on the number of 3rd party libraries required.

MEF

The Managed Extensibility Framework (MEF) is a new library in .NET that enables greater reuse of applications and components. Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed. If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you.

Extensibility! The decision to use MEF at such an early stage was purely academic but the result is perfect. I only wanted to code for the common scenarios.

In the environment I worked the process was very manual with SharePoint forms being touted as progress…I planed on writing a class library that implemented ICustomTask and called WaitN to fill out the endless, mind-numbing, pointless, wasteful, costly, wow….sorry..off track.

Unity

The Unity Application Block (Unity) is a lightweight extensible dependency injection container with support for constructor, property, and method call injection.

I choose unity because I am familiar with it. I should have used ninject or autofac or StructureMap or .. well you get the point.

Fluent Interface

A fluent interface is a way of implementing an object oriented API in a way that aims to provide for more readable code.

It started off as a way to work with the buzz word of the day…but the first time I wrote an AutoDeploy.NET parent application using the fluent interface I was hooked!

Point In Time

I made, what I consider, significent progress on AutoDeploy.NET before parting ways with said organization. And while I hope to never ever need such a tool I feel for those solders I left behind. Seriously; we’ve identified many different scenarios where automating one or more of the common deployment tasks would be helpful to any developer.

Logging, Auditing and Messaging are the missing pieces at this time.

, , , , , ,

AutoDeploy – Dogfood

Jul 1st

Posted by Eric Polerecky in autodeploy

No comments

Its been a very slow road for me and coding the last few weeks. Between constant meetings and having to rebuild my home workstation (beta –> RC), I’m surprised I’ve got anything done.

Current Status

AutoDeploy consists of internal services and a task is simply a container for the service definition and required attributes. the current services and completion % (total guess…there is no road-map so its pretty hard too tell)

  1. ASP.NET Build – 80%
  2. C# Build– 80%
  3. Custom Task (MEF) – 80%
  4. Database Migration – Not Started
  5. Email – 80%
  6. FileCopy – 80%
  7. Folder Monitor – 80%
  8. Ftp – 80%
  9. MS SQL Script – Not Started
  10. Subversion – 90%
  11. Vb Build – 80%
  12. Zip Compress – Not Started

Those listed with 80% function but have limited logging. Logging has been my biggest challenge. I want to ensure the logging (status, audit, etc) is available to the host program. AutoDeploy is only a dll and I’m having a hard time finding the best implementation to ensure that messages flow back to the host.

Without any more delay I present the current hotness…

The fluent interface (take 2)

   1:  var deployment = new Deployment();
   2:      deployment
   3:          .Named("PROJECTNAME")
   4:          .AtInterval(1)
   5:          .AddTask(
   6:              new FluentTask()
   7:              .Type(Task.TaskType.FolderMonitor)
   8:              .Source("http://REPO/tags/")
   9:              .Destination(@"D:\Temp\")
  10:              .Authentication()
  11:              .Credential(new NetworkCredential(@"UID","PASS"))
  12:              .Save()
  13:      )
  14:      .AddTask(
  15:          new FluentTask()
  16:          .Type(Task.TaskType.AspnetBuild)
  17:          .Save()
  18:      )
  19:      .AddTask(
  20:          new FluentTask()
  21:          .Type(Task.TaskType.FileCopy)
  22:          .Destination(@"\\SERVER_OR_LOCAL\Deployment")
  23:          .Save()
  24:      )
  25:      .AddCustomTask("WaitN")
  26:      .Save();
 
 
 

 

Changes of Note:

  1. Source and destination can be omitted and left to convention. In the second task there is no source or destination. The source will be the destination of the pervious task. The destination will be the destination of the pervious task plus the deployment name.

Classic Usage

 

   1:  var _deploymentContainer = DeploymentContainer.GetInstance;
   2:  var deployment = new Deployment();
   3:  deployment.Name = "PROJECT";
   4:  deployment.Interval = 5;
   5:   
   6:  var monitorTask = new Task();
   7:  monitorTask.Type = Task.TaskType.FolderMonitor;
   8:  monitorTask.Source = "http://subversion/repo/tags/";
   9:  monitorTask.Destination = @"C:\Temp\";
  10:  monitorTask.Authentication.Credentials _
  11:   = new NetworkCredential(@"DOMAIN\PolerckyE", "PASSWORD");
  12:   
  13:  deployment.AddTask(monitorTask);
  14:   
  15:  var buildTask = new Task();
  16:  buildTask.Type = Task.TaskType.AspnetBuild;
  17:  deployment.AddTask(buildTask);
  18:   
  19:  var copyTask = new Task();
  20:  copyTask.Type = Task.TaskType.FileCopy;
  21:  copyTask.Destination = @"\\ServerName\path\";
  22:  deployment.AddTask(copyTask);
  23:   
  24:  deployment.AddCustomTask("WaitN");
  25:   
  26:  _deploymentContainer.AddDeployment(deployment);
, , , , , ,

AutoDeploy Rework

Jun 12th

Posted by Eric Polerecky in autodeploy

No comments

Tonight I reworked in workflow, persistence, mapping, and entities in AutoDeploy. The fire draft consisted of a single entity type with long descriptive janky attributes. The new core goes something like this

Deployment has a list of tasks. Tasks can be have a task type.

Example 1 Creating a new deployment:
   1:  var dep = new Deployment()
   2:  .AddTask(
   3:     new FluentTask()
   4:       .Source("")
   5:       .Destination("")
   6:       .Type(Task.TaskType.Subversion)
   7:       .Save())
   8:  .AddTask(
   9:    new FluentTask()
  10:       .Source("")
  11:       .Destination("")
  12:       .Type(Task.TaskType.AspnetBuild)
  13:       .Save()
  14:  );
 
Deployments and Tasks can be scheduled or interval execution. I’m thinking right now that Task level interval settings will override deployment settings. This will allow you to schedule an entire deployment at X with a single task happening outside of that window. For example; you might want your working copy updated every 10min but have trunk moved to the dev server, an tag created and an email sent off at the end of the day.
 
,

Introducing: AutoDeploy

Jun 11th

Posted by Eric Polerecky in autodeploy

No comments

A class library to help automate simple deployment tasks.

Warning: pre-alpha.

AutoDeploy has 2 main components; deployment objects and a deployment controller. A deployment object holds n+1 deployment tasks. The deployment controller is responsible for executing scheduled, interval and on demand deployment tasks.

AutoDeploy is complete enough for me to start dog fooding it this week. I’ll have a road-map soon after.

Features
  1. Deployment Controller
  2. Scheduled Deployments
  3. Interval Deployments
  4. SVN Checkout
  5. SVN Commit
  6. ASP.NET Build
Example 1: Fluent Interface, SVN Checkout, Interval 
   1:  var deploymentController = AutoDeploy.Controllers.DeploymentController.GetInstance;
   2:  new AutoDeploy.Mappings.FluentMapping().Named("TestMapping")
   3:  .FromSvnHttpRepositoryUrl("URL")
   4:  .UsingSvnCredentials(new System.Net.NetworkCredential("UID", "PASS"))
   5:  .SvnCheckoutToDirectory("C:/Temp")
   6:  .AtTime(6)
   7:  .Save();

First, or last, or never..we create a controller. The controller will check every minute for interval and scheduled deployments. In this example we checkout every day @ 6am.

Example 1: Fluent Interface, Compile, Publish, One Time
   1:  new AutoDeploy.Mappings.FluentMapping()
   2:  .SvnCheckoutToDirectory("C:/Temp")
   3:  .BuildAndOutputToDirectory("C:/TempCompiled")
   4:  .Execute();

shhh..I know the source directory name is horrible…

, , ,