Deployment Automation Framework v.Joseph

whinnycampingΜηχανική

5 Νοε 2013 (πριν από 3 χρόνια και 5 μήνες)

79 εμφανίσεις

Contents

Deployment Automation Framework v.Joseph

................................
................................
................................
..........
1

-

Process Implementation
................................
................................
................................
............................
1

Suppor
ts
................................
................................
................................
................................
..............................
1

Leveraging

................................
................................
................................
................................
..........................
2

Setup

................................
................................
................................
................................
................................
...
2

Extending

................................
................................
................................
................................
............................
3

-

Console Implementation

................................
................................
................................
...........................
3

Suppor
ts
................................
................................
................................
................................
..............................
4

Leveraging

................................
................................
................................
................................
..........................
4

Setup

................................
................................
................................
................................
................................
...
6


D
eployment Automation Framework v.Joseph

The deployment automation framework is intended to leverage the K2 APIs that are involved in importing and
exporting key settings that are commonly replicated between development, testing and production K2 servers.

Additionally, the process based impleme
ntation provides an avenue for a k2proj and related files to be added to
a DeploymentPackage, built on the appropriate server according to the process flow and deployed on the target
server.


There are two implementations of the DeploymentAutomation librar
ies included here. The first is a process,
smartobject, aspx and web service framework for automating change control via the included libraries. The
second is a simpler but easily expanded implementation used for support activities and has been available

on
UG for some time.

Process Implementation

Supports

At present the key settings needed are supported with the exception of permissions. This includes



K2 Environment Libraries and the various variables included there



K2 Service Types and Instances maint
aining GUID integrity



K2 Roles including user, group and SmartObject based roles



K2 Process and Action Permissions can be exported only

(
It would not be difficult to implement permissions importing, but it was judged that this would
be a potentially risky
set of methods to expose to business users.
)

Leveraging

The Deployment Automation Framework is broken down in several pieces that can be used individually or as a
whole.



DeploymentAutomation (DepAuto) Library: This library contains serializable objects,
nested/overloaded
methods to ease the import and export of individual objects all to be utilized by user applications or
services. It contains everything you need to succes
sfully package a project and it
s environment into a
zip or SmartObject record excep
t for the ability to create an msbuild package from the project.



DeploymentAutomation.
ProjectCompilation
Library: The library is isolated from the DepAuto library in
order to limit the number of dependency dlls require by the core DepAuto library. This li
brary contains
methods for creating the msbuild package from a particular project or set of projects.



DepAuto.exe Console Application: This utility is intended to offer a subset of the
DeploymentAutomation library’s capabilities in order to
facilitate

the
scripting of Environment, Role and
Service Type/Instance movement b
etween K2 Servers. In addition to import/export of these, it does
also

exporting of the process and action permissions

Setup

1.

Copy the DeploymentAutomation.dll and
DeploymentAutomation.Proj
ectCompilation.dll

to c:
\
program
files
\
DeploymentAutomation
\
bin and GAC them.

2.

Open the DeploymentAutomation Solution, and publish the DeploymentAutomationWebService to:
http://[k2servern
ame]/workspace/DeploymentAutomation

3.

Open the DeploymentAutomationWeb Solution and publish to
http://[k2servername]/workspace/depauto

4.

Install David Loomis’
Dynamic Assembly Service

using the installer from the K2 Underground project
repository

5.

Use the depauto.exe tool to import the service instances required by the DepAuto SmartObject
s by
performing:

depauto.exe /importzip:[path to DepAutoK2 solution
folder]
\
DepAutoConfig
.zip

6.

Open the DeploymentAutomationK2 Solution, publish SmartObjects and then publish Processes

7.

Consider the target environment and the type of authentication that wi
ll be used there. The included
SmartObject

methods provide alternate methods of authentication, but in the processes implemented
at the time of this writing,
you need to enable anonymous access for the Web Service’s IIS virtual
directory in order for it t
o work ootb
.
Otherwise, modify the process to include a username password
by choosing the appropriate SmartObject method (an overload) OR implement your own security within
the ServiceMethods class of the DeploymentAutomation library OR implement your own

security within
the DeploymentPackages class within the
WebServiceSend or SendDeploymentPackage
methods.

8.

Assign start and view permissions as appropriate for all of the deployed proce
sses. With the exception
of the “StartDeploymentAutomation” process, ty
pically all processes
need “Start” permissions assigned
for the K2 service account.
The “StartDeploymentAutomation” process will need start rights assigned
for any users who are permitted to add a completed project to the deployment workflow.
Others will

need for any participating users/groups to have view or view/participate permissions in order to review
results via the provided “ViewFlow” report urls within the aspx forms UI.

Extending

There are several levels where the framework will need to be worked

into your own specific environment.
Depending on the way your development and QA team works you may leverage only small portions of the
included package or perhaps just the consol application.

The following are points to consider when getting a feel for
what works and what will need to be smoothed into
your own implementation.

1.

As mentioned in point 7 above, a decision was not really made within this application as to what
methods to use in authenticating with the web services running on a target server as

a package is rolled
up from Development to QA (for instance). As I mentioned, right now you’ll need to just enable
anonymous and perhaps limit that site to only accept requests from the K2 server that should be
allowed to send such requests. Beyond that
, you’ll need to make observations regarding your domain
setup, trusts involved, Kerberos concerns etc. etc and implement an authentication method for that web
service that is appropriate.

2.

I built an option into the process design that can be either easily

implemented or easily removed.
Within the StartDeploymentAutomation process there is an action/Client Event option within “Compile
Local” path in which you can implement a call from the web page to hit the web service hosted on the
target server to retri
eve roles, environments and service types/
instances
. Using methods already in
place within the deploymentautomation.dll this will be a snap, but it is not implemented yet.

3.

I had always planned to leverage the real objects that are represented by the envir
onments, roles and
services xml. At the time of this writing, I have provided a few text boxes within the UI to make the edits
as I haven’t found a cool enough control to do what I want yet.

4.

You may be thinking: Boy, I like the depauto.exe application bec
ause it is so much simpler and I can just
make my own msbuild packages and use my source control system to manage that portion of things.
This is true, however, in many cases this approach breaks down when

a.

You are asked to provide good reporting on the s
tatus of a particular project build (without
writing a bunch of your own reports)

b.

You want to track testing in addition to deployment in these reports

c.

You want to float the packages directly to Production in a speedy manner without starting over
with a new

thread

d.

You want to leverage K2s rich role and worklist management to automate, escalate, manage and
monitor these tasks

e.

You need very airtight reporting for legal compliance

f.

You realize how silly it is to have 3 systems managing tasks, bottlenecks and
resources
throughout your enterprise when K2 can do it all

Console Implementation

The console implementation does not have all of the capabilities possible implement from the
DeploymentAutomation libraries. It is a subset that is more focused on:

-

Import/E
xport of configuration settings

-

Packaging of settings and if argument supplied, a k2proj file and related files

Supports

At present the console app supports:

-

Export, Packaging and Import of:

o

Roles (all types)

o

Environments

o

Service Types and Instances

-

Export

and Packaging of:

o

All of the above

o

Process and action permissions

o

A single project file

Leveraging

Use of the command
-
line is described in the /? Of the utility but here are a few
step by step scenarios to get
started:

I want to create a new environment i
n BlackPoint:

-

From the command line: depauto.exe

-

Creates a file called “localhostExport.zip”

-

Open “localhostExport.zip” and unpack ALL of the xml files to a temp directory

-

Get rid of these files, they do not affect an environment import: roles.xml, servi
ces.xml,
permissions.xml (leave the content and environments.xml files in place)

-

Open the environments.xml file in a text editor

-

Note that you see two <environment … nodes. You can delete one of these now.

-

With the remaining <environment .. node
, modify it’s name and it’s Guid.

o

Name it how you want it to appear, for instance “QA”

o

Change any character of the GUID that you want to something else, chances are you will not end
up with a conflicting GUID. (HOWEVER, YOU DO have to change it)

-

Zip up th
e two xml files remaining and name it “localhostEnvironmentQA.zip” or whatever you like;
place the zip file alongside the depauto.exe for ease of use. Or don’t and be sure to use quotes around a
file path with long names or spaces.

-

Run the command: depaut
o.exe /importzip:localhostEnvironmentQA.zip

-

If you make changes to the xml file and want to overwrite a previous import, run the command with
/overwrite:true as the final argument

I want to migrate

my environment settings, roles and service instances from
one server to another:

-

Commandline: depauto.exe

-

Unzip and inspect each of the xml files, here are some pointers

o

Services.xml: Most of the ootb service instances will be ignored. They are configured by the K2
Configuration Wizard and probably shouldn’t be
ported around, however, the SQL Reporting
service type seems ootb, but could contain instances that you want to migrate


this one is
allowed

o

Services.xml: Make sure that if any of your service types or instances leverage dlls that you take
the time to ins
tall the applications or libraries necessary in the target environment. This utility
only imports the info into K2 and will error if you try to import and a dependency is missing

o

Roles.xml: Be absolutely sure, if you are migrating from one domain to anoth
er that the
members of the roles you are importing are accurate. It will not warn you if you add bad users.

o

Roles.xml: Be also sure that any SmartObject based roles have the proper smartobjects
deployed. You can see this easily when inspecting the roles
xml itself

o

Environments.xml: It is common for confusion to abound regarding the implementation and
configuration of environments. Be sure that you have a good handle as to where your project
msbuild files are being created. If you are not creating msbuil
d files on your production server,
you do not need to configure or import environment there (the settings are saved from the
environment where the msbuild file is compiled


inside the .msbuild file itself)

o

Environments.xml: When modifying these values, b
e careful whether you are editing values
within the “Development” or “Production” or other <environment.. node. I have accidentally
modified the production value instead of development when making changes in notepad.

o

Permissions: do not import, only expo
rt for inspection

o

Double check everything. While this is a huge time
-
saver and can be easily scripted and
automated, it can be dangerous too, so be sure to check out the settings you impor
t via
Workspace Management and
confirm that you did what you
want
.

o

Backup before importing.

-

On the target server

import using the following:

o

First use: d
epauto.exe /importzip:youredittedzipfile.zip

o

Then if necessary:

depauto.exe /importzip:youredittedzipfile.zip /overwrite:true

You want to backup

config settings for
pick and choose backups later or while testing other software to
synchronize these settings:

-

Create the backup zip file with the commandline: depauto.exe

-

Modify the contents of the zip file, if you want to exclude anything from restore

-

Restore with the
commandline: depauto.exe /importzip:yourbackup.zip /overwrite:true

I want to import a large number of SQL based roles into K2 roles

-

Create the roles.xml file based on the structure provided by a test export

-

(don’t forget include the content..xml file.. it

is required for the utility to be able to unzip the import file)

-

Import and test using the commandline:

depauto /importzip:zipfilecontainingyourroles.zip

-

Import and overwrite ongoing: depauto /importzip:zipfilecontainingyourroles.zip /overwrite:true

I ne
ed to package up everything for someone else to deploy my project

in their environment (my peer, my
support rep, my client)

-

Commandline: same as a normal export, except supply the full path to the k2proj file as it resides in it’s
working directory for the

commandline argument, for instance

depauto.exe /project:”c:
\
documents and settings
\
joseph
\
desktop
\
solution
\
proj
\
proj.k2proj”

Setup

To setup depauto, download it from
http://www
.k2underground.com/k2/ProjectHome.aspx?ProjectID=104

Unzip the exe and dll to a directory on your K2 Server (always run on the K2 Server itself)