In my previous post I tried to make it clear that continuous production is for good. This post I’ll show how to prepare environment for continuous production. The idea is that you should be able to configure and test it locally. All configurations have to be part of source code under SCM. It should not depend on machine and run any environment you like. Success criteria is: pick up clean machine, do checkout, run build.bat/deploy.bat and have installed web application.
Integration and database deployment
As I said, UppercuT and RoundhousE are really nice tools for that. As soon as you follow the instruction’s you will have a build.bat, that would be able to build up all binaries, run tests against that and put all build artifacts to package. That is pretty good for start, but we still missing “deployment” part.
As you a little bit more familiar with UppercuT, it provides good facilities for deployment as well. Basically, there are folder deployment\templates\ where you able to define your custom deployment scripts. Typical web application requires 2 scripts:
- AppDeployment.bat - for web site deployment
- DbDeployment.bat - for database deployment
There files are templates, from which script for particular environment is generated. The environment is defined in settings folder and include such information as deploy folder, web site name, database name, server name as number of variables. Example,
<?xml version="1.0" encoding="utf-8" ?>
<project name="Settings">
<!-- environment settings -->
<property name="environment" value="PRODUCTION" />
<!-- servers -->
<property name="server.database" value=".\SQLEXPRESS" />
<property name="web.deploy.folder" value="c:\trackyt.net\web\" />
<property name="web.site.name" value="trackyt.net" />
<property name="database.name" value="trackytdb" />
<property name="log.level" value="DEBUG" />
<property name="app.user.name" value="alexander.beletsky" />
<!-- base settings -->
<property name="project.name" value="trackyt.net" overwrite="false" />
<property name="repository.path" value="git://github.com/alexbeletsky/trackyt.net" />
<property name="folder.app.drop" value="${project.name}" overwrite="false" />
<property name="folder.database" value="db" overwrite="false" />
<!-- database deployment -->
<property name="dirs.db" value="..\${folder.database}" />
<property name="file.version" value="_BuildInfo.xml" overwrite="false" />
<property name="restore.from.path" value="..\${database.name}.bak" overwrite="false" />
</project>
In template .bat file it is possible to refer, to some particular variable, so it is possible to make those quite generic. After build, template .bat files are post-processed and actual batch is generated. The name would be like ENVIRONMENT.AppDeployment.bat, where ENVIRONMENT is type of environment you defined.
Web site deployment script
If you do ASP.net (MVC) website in 99.9% cases you will be happy with simple XCOPY deployment type. Basically it means, simple copy of website to defined IIS folder.
But, as soon it is continuous production deploy it means that Web Site is already running. It would not be possible to re-write some files, since they could be used by IIS. So, we need to stop the site before update. I found very good possibility for that with %windir%\system32\inetsrv\appcmd command. After site is stopped, we just copy full content of Web folder, remove some redundant files and run site again. In batch code it would look like,
@echo off
SET DIR=%~d0%~p0%
SET web.deploy.folder="${web.deploy.folder}"
echo stopping web site..
call %windir%\system32\inetsrv\appcmd stop site ${web.site.name}
if %ERRORLEVEL% NEQ 0 goto errors
echo copy application content
rmdir /s /q %web.deploy.folder%
xcopy /E /F /H /R ..\_PublishedWebSites\Web %web.deploy.folder%
xcopy ..\build_artifacts\_BuildInfo.xml %web.deploy.folder%
if %ERRORLEVEL% NEQ 0 goto errors
echo remove redudant files
del %web.deploy.folder%*Tests*.htm*
del %web.deploy.folder%Web.Debug.config
del %web.deploy.folder%Web.Release.config
del %web.deploy.folder%*packages*
if %ERRORLEVEL% NEQ 0 goto errors
echo starting web site
%windir%\system32\inetsrv\appcmd start site ${web.site.name}
if %ERRORLEVEL% NEQ 0 goto errors
goto finish
:errors
EXIT /B %ERRORLEVEL%
:finish
Database deployment script
RoundhousE does all infrastructure work for us. All we need to create a batch file, that would be able to run during continuous production cycle. As well as AppDeployment.bat I defined DbDeployment.bat in deployment\templates\ folder. But before any update of database it is always good to have a backup, to be able to restore from it if something went wrong. Actually, RoundhousE should have such ability, but unfortunately I didn’t get how to use it. I’ve created my simple SQL script that is able to backup.
USE $(Database);
GO
BACKUP DATABASE $(Database)
TO DISK = 'C:\backup\$(Database).bak'
WITH FORMAT,
MEDIANAME = 'C_SQLServerBackups',
NAME = 'Full Backup of $(Database)';
GO
And corresponding batch file, that would run backup.sql.
@echo off if '%1' == '' goto usage if '%2' == '' goto usage sqlcmd -S %1 -i .\scripts\backupdb.sql -v Database = %2 -e if %ERRORLEVEL% NEQ 0 goto errors goto finish :usage echo. echo Usage: backup.bat [server] [database] echo [server] - server eg. mymachine\SQLEXPRESS echo [database] - name of database to backup echo. EXIT /B 1 :errors EXIT /B %ERRORLEVEL% :finish
Both files are placed into deployment\scripts folder. So, the DbDeployment.bat template, would first run database backup and if it is successfull, run RoundhousE to update database.
@echo off
SET database.name="${database.name}"
SET sql.files.directory="${dirs.db}"
SET server.database="${server.database}"
SET repository.path="${repository.path}"
SET version.file="${file.version}"
SET version.xpath="//buildInfo/version"
SET environment="${environment}"
echo backup database
call .\scripts\backupdb.bat %server.database% %database.name%
if %ERRORLEVEL% NEQ 0 goto errors
echo update database
"%DIR%rh\rh.exe" /d=%database.name% /f=%sql.files.directory% /s=%server.database% /vf=%version.file% /vx=%version.xpath% /r=%repository.path% /env=%environment% --ni --simple
if %ERRORLEVEL% NEQ 0 goto errors
goto finish
:errors
EXIT /B %ERRORLEVEL%
:finish
Putting it all together
We already have build.bat as part of UppercuT, now we need to define deploy.bat that would do deployment of product. It would be called immediately after build.bat finished, so binaries are ready, tests passed and code_drop folder contains all artifacts for deployment. The script is rather simple and utilize stuff we did previously.
@echo off if '%1' == '' goto usage SET ENV=%1 cd .\code_drop\deployment echo Deploy database call .\%ENV%.DbDeployment.bat if %ERRORLEVEL% NEQ 0 goto errors echo Deploy application call .\%ENV%.AppDeployment.bat if %ERRORLEVEL% NEQ 0 goto errors goto finish :usage echo. echo tracky.net deploy script echo Usage: deploy.bat [environment] echo [environment] - deployment environment could be STAGING or PRODUCTION echo. EXIT /B 1 :errors echo Build FAILED EXIT /B %ERRORLEVEL% :finish echo Build SUCCESS
Notice, it receives the parameter ENV. It will contain type of environment for deployment. For staging environment, you should call deploy.bar STAGING, for production deploy.bat PRODUCTION.
Testing it out
That’s basically it. Now, you should make sure everything works as expected. Run build.bat/deploy.bat, make sure build went with no errors, deploy.bat correctly does back up of database, updates database and update site content.
As I said on top, it is very important that configuration is part of product, part of source code. If you follow this, it will be possible to deploy application but just getting sources from SCM. This is first step of setting up your Continuous Production server.