Wipcore eNOVA Continuous Integration



Continuous Integration with eNOVA TOC \o "1-3" \h \z \u Continuous Integration with eNOVA PAGEREF _Toc305672050 \h 1Introduction PAGEREF _Toc305672051 \h 2Background PAGEREF _Toc305672052 \h 2Benefits PAGEREF _Toc305672053 \h 2Requirements PAGEREF _Toc305672054 \h 2Building and deploying using scripts PAGEREF _Toc305672055 \h 2Automating builds and testing with TeamCity PAGEREF _Toc305672056 \h 7Summary PAGEREF _Toc305672057 \h 14IntroductionThis document contains guidelines for how to work with continuous integration in eNOVA projects.BackgroundContinuous integration is a software engineering practice that aims to improve the quality of software and reduce development time. This is done by integrating early and often as well as applying quality control frequently. The recommended approach for accomplishing this is to automate builds and testing as much as possible so that it requires no additional time or effort from the development team to perform many times per day.BenefitsThere are many benefits of using continuous integration, such as:Self-testing builds – Catches bugs early when they are inexpensive to fix.Constant availability – A current build is always available for testing, demo or release purposes.Regression testing – Ensures that all tests are run continuously, to catch errors that are introduced as the software evolves.Avoid last-minute release chaos – A runnable version of the system is built every day which makes it trivial to rollback in case of problems.Statistics – Provides statistics about the quality of the software.These are just a few advantages of continuous integration and some of these steps require you to also use unit testing to get the most out of it. However, we think this is a great way of developing software and we highly recommend it.RequirementsThere are a few requirements that need to be fulfilled before getting started with continuous integration. They may seem obvious to most developers, but yet there are still companies who do not exercise these very fundamental practices.Your source code must be handled by a version control system (sometimes called revision or source control software). For example, Team Foundation System or Subversion.You need a continuous integration server, such as Team Foundation System, TeamCity or .We highly recommend that you write unit tests to verify your code.Building and deploying using scriptsTo make it easy to build and deploy a project that uses Wipcore WebFoundation we have created a set of sample scripts that can be used for this purpose. The scripts should be considered as starting points as they need modifications to work in your projects. We have also created a script to make it easy to upgrade a solution whenever a new version of WebFoundation is released.One benefit of using these scripts is that once you have made the initial configuration you don’t have to touch them again. If you add a new project in your solution you don’t have to add any xcopy statements or change anything other than just adding a project reference.All of these sample scripts are located in the Wipcore.WebFoundation folder. The scripts are:DeployTest.cmd – Deploys a project to a test server.DeployDemo.cmd – Deploys a project to a demo server.UpdateProjectFromWebfoundation.cmd – Upgrades your project to a new version.Build.cmd – Performs a complete build and optionally publishes a web project.CopyDatabaseFromTestToDemo.cmd– makes a complete backup and restore between test and demo environments. In most customer solutions this is just recommended initially in the project, later you want to check if all data configuration is moved from test to demo before production.These scripts can be used with a little modification in your projects as well. The following sections explain how to use them.Note that some of the scripts contain commands for working with Team Foundation Server to retrieve source code. You need to remove these or replace them with commands that are appropriate for your version control system if you use another product.Updating your test serverMany projects have a testing server where the project can be deployed in order to verify that all parts work together. Having a dedicated test machine that resembles the production environment is a good idea to catch any deployment problems or bugs early in the development cycle.To update your test server you can use the DeployTest.cmd script. Copy this file into your project and update the variables in the script to match your environment.If you want to avoid overwriting certain files (such as web.config for example) or maybe skip certain files you can add them to the excludeFilesWeb.txt file.Updating your demo serverIf you have a dedicated server for demo purposes you can use the DeployDemo.cmd script to update it. This script also has support for copying a database from the test server to the demo environment if needed.To update your demo server you copy the DeployDemo.cmd file into your project and update all the variables to match your environment.Updating your production serverUpdating a production server is sometimes tricky and this may vary a lot depending on the environment that you are deploying to. Because it is hard to hard to make a generic solution that fits every situation we are only providing a very simple solution, but in many cases this may be enough to get you started.We have provided a sample script called Build.cmd script that performs a complete release build with a publish step that will package up a zip file containing your website. This zip-file can be uploaded to your production environment and then you can unpack it and run a script like DeployDemo.cmd to perform a complete deploy. You can run Build.cmd without any parameters to perform this default operation.Note that the build script is used by other deploy scripts as well so you need to ensure that you configure it correctly.Upgrading your projectIf you follow the structure of the WebFoundation Sandbox project you can use our sample scripts as a convenient way to upgrade your project when a new release is available. The script can be found in the Wipcore.WebFoundation folder and it is called UpdateProjectFromWebfoundation.cmd. Copy this file into your project before you modify it.To update your project you follow these steps:Change the “webfoundation” variable in the UpdateProjectFromWebfoundation.cmd script so that it points to the folder where the latest version of WebFoundation can be found.Run the script from a command line pile your project and solve any errors that may occur due to breaking changes.Now optionally, run DeployTest.cmd or DeployDemo.cmd to update your servers.Handling configuration settingsWe strongly recommend that all settings are kept under version control at all times. Don’t change settings in the production environment without also backing them up using source control. Instead of changing things in the production environment, make changes in source controlled files and use automated deploy scripts to ensure that the same settings are sent to all destination servers. One important thing to remember is that if you change IIS settings on a production server this may lead to the web.config file being changed. These changes may then be overwritten when the project is deployed which leads to unnecessary manual work. One thing that can be a bit tricky is how to manage configuration settings for different environments. You may need one setting when running locally on your development machine, another one in your test environment and yet another in your production environment. This is common for settings such as the database connection string, log file paths and levels etc.Out of the box Microsoft web application deployment supports something called Web.config Transformation. This allows you to transform the web.config file using a couple of extra files called Web.debug.config and Web.release.config that contain the settings that should be changed when building the project with the particular configuration. This works well for most web projects that have a small amount of settings. However, the problem with this technique is that it is only supported for the Web.config file. In WebFoundation projects we have other configuration files such as startup_settings.xml that also needs to be transformed in this way. This is not supported with the standard tools.Luckily there is a quite convenient way to accomplish this today that we use and that is a Visual Studio extension called SlowCheetah. You can find it here: you install this tool you can simply right click any config file or xml file and click “Add Transform” and SlowCheetah will automatically update your project file with the required modifications. When you build your project (or publish in case of a web project) the transformed file will be produced in the output directory.Note that if you want the transformations to work also on machines that have not installed SlowCheetah you can simply copy the SlowCheetah MSBuild target file and DLL into your own project, for example in a “Tools” folder, and add this to source control. Then you can simply update your project file to point to this local MSBuild target and it will work for everyone, even if they have not installed the VS extension.This is how you can modify your project file to use a local version of the SlowCheetah target:??<PropertyGroup>????<SlowCheetahTargets?Condition="?'$(SlowCheetahTargets)'==''?">..\Tools\SlowCheetah\SlowCheetah.Transforms.targets</SlowCheetahTargets>??</PropertyGroup>??<Import?Project="$(SlowCheetahTargets)"?Condition="Exists('$(SlowCheetahTargets)')"?/>Make sure you copy the files from the default location $(LOCALAPPDATA)\Microsoft\MSBuild\SlowCheetah\v1\SlowCheetah.Transforms.targets into your project. In our example above we have copied the targets file and the DLL to a folder called Tools\SlowCheetah.Solution and project settingsThe sample solution for WebFoundation contains a folder called “MyCustomerSolution” and under that you can find the “Deploy” folder. In that folder we have placed projects that should be deployed to the destination. These projects contain the precompiled versions of the external DLLs needed in your project (webfoundation and Enova). All content in this projects should be marked with “Copy Always”Except files which you want to xml tansform, like config.xml in search.And optionally nlog.config in integration if nlog is used.The dll’s in the projects under Dependencies will be updated after each new enova/WF release with the command: UpdateProjectFromWebfoundation.cmd. So for easy upgrade keep this projects clean from customer project files except config files with xml transformation. We encourage you for reusability of code to organize your code in small projects. This projects can easily be included in the deploy with just adding a project reference to desired project under deploy. If you for instance makes an Enova class project you want to add a project reference to all projects under deploy.The purpose if this project structure is that you don’t need to collect dll’s manually or by script to update your production or test environment. All files is already structured under integration/bin/release, search/bin/release etc.Another important thing is that your web project needs to contain a special target that is used for publishing files. Just add this to your .csproj file and it should work:??<Target?Name="PublishToFileSystem" ?DependsOnTargets="PipelinePreDeployCopyAllFilesToOneFolder">????<Error?Condition="'$(PublishDestination)'==''" ?Text="The?PublishDestination?property?must?be?set?to ?the?intended?publishing?destination."?/>????<MakeDir?Condition="!Exists($(PublishDestination))" ?Directories="$(PublishDestination)"?/>????<ItemGroup>??????<PublishFiles?Include="$(_PackageTempDir)\**\*.*"?/>????</ItemGroup>????<Copy?SourceFiles="@(PublishFiles)" DestinationFiles="@(PublishFiles->'$(PublishDestination)\%(RecursiveDir)%(Filename)%(Extension)')" ?SkipUnchangedFiles="True"?/>??</Target>You can take a look at the project file for the Sandbox, Wipcore.WebFoundation.Web.Sandbox.csproj, if you want to see an example of where to put it. If you want your web project to be zipped this step is not mandatory.Deployment procedureThis is an overview of how the deployment procedure works in a typical project. The arrows illustrate how files are copied to the different locations.UpdateEnovaRelease.cmd – This is used internally at Wipcore when updating the Sandbox with the latest eNOVA release.UpdateProjectFromWebfoundation.cmd – This can be used in your own projects to upgrade with the latest from the Sandbox project.DeployTest.cmd – This can be used to deploy from your customer solution to the test server.DeployDemo.cmd – This can be used to deploy from your customer solution to the demo server.Automating builds and testing with TeamCitySetting up a new build configuration using TeamCity is quite straight forward. These are the steps that you have to go through.General settingsFirst of all you need to setup some initial parameters for the build, such as the name and description. You can leave most settings at the default here.Version Control SettingsThe next thing you have to specify is where TeamCity can find your source code. TeamCity has support for a wide variety of popular version control systems, such as Team Foundation Server, Subversion, Git etc. In our example below we have setup a TFS source control root which points to the folder where our solution files reside. TeamCity will retrieve this entire folder so you should point it to a folder that contains everything you need to build your solution but nothing more.You can also tell TeamCity to label the exact version of the source code that was used in the build. This is useful if you need to backtrack in your version history which code was used to build a certain version of your project.Build stepsAfter those two screens have been setup you can add one or more build steps. A build step is one discrete operation that needs to be performed to build your project. For example, this could be to build a project or solution, to run all tests, to execute some custom scripts and even to deploy everything to a server.In our example screen below we have defined a build step that compiles a complete Visual Studio solution. All you have to do is to specify the path to a solution file and TeamCity takes care of the rest (Visual Studio must be installed on the build agent for this to work).The build steps are executed in order and the build will stop if one step fails. In the screen below we have setup the second build step to run all the unit tests for the project. TeamCity supports the most popular unit test frameworks such as MSTest, NUnit etc. We have added an exclude filter to ensure that TeamCity does not pick up DLL-files from the “obj” folder.Build TriggeringAfter you have setup the build steps you are actually done. The build can now be run manually whenever you want which is nice.However, since we want to automate things we want to ensure that this is run continuously. This is done by using build triggering. In the screen below we have configured a build that runs every night.For a true continuous integration scenario you would want to configure a build trigger that runs in every time new code is checked in. This helps to catch problems as early as possible so that they can be fixed before the code affects anyone else, or even worse – before it is deployed in production.To set this up in TeamCity, click the “Add new trigger” link and specify to use the VCS Trigger:You can mix and match triggers as you like for a single build. Here is an example of our continuous build using a trigger that builds whenever someone checks in code:Build ConfigurationsWe have found that it works quite well to have separate builds that triggers on a schedule and on check-ins. We call them the continuous build and the nightly build. This is an example of how this may look in TeamCity:The continuous build is built whenever the code changes and it runs pretty fast to ensure that the solution compiles and integrates with other parts. Short running unit tests should also be executed during these builds to verify that the internal behavior has not broken.The nightly build is made to be more thorough and takes longer to run. It will compile and integrate as much as possible, run all tests including the long running system integration tests and if everything passes it may also deploy everything to a testing server. This ensures that there is always a new fresh test version of the project available every day.Deploying from the build serverIf you have setup the deploy scripts correctly it is quite trivial to deploy directly from the build server. In the case of TeamCity it is only a matter of adding an additional build step to run the actual script. This is how it is done:This can be setup as a final step in your nightly build to automatically deploy to a testing server if the build was successful. Since it is running automatically you will ensure that you always have an up-to-date version of your project ready on your test server at all times.SummarySetting up a continuous integration server for the first time may take some time. You need a build server and you have to create build configurations to do what you want. However, with tools such as TeamCity this has now become easier than ever. Besides, even though you pay an initial cost to get it all working it will usually pay off many times over the course of the project because once you have it running it will be there in the background doing its work and assuring that nothing breaks.If you couple this with extensive use of unit testing you will soon discover that the quality of your projects increases. Not only that, but the developers of the project can relax knowing that the system is being continuously verified and tested to ensure that the things that were built several months ago still works today. That’s a truly comforting feeling!Hopefully this has given you inspiration to start working with continuous integration to make your projects successful and your customers happy!Thank you for using Wipcore eNOVA! ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download