Is it possible to do Continuous integration.
We are using Power shell script to deploy BTDF packages. I found many resources to do continuous integration for BizTalk using TFS but is it possible to do continuous integration. Is there any resources available for the same.
Well, consider "continuous integration" is a pattern, not a thing. So sure, you absolutely can do CI with BizTalk apps using a SVN. Really, the code repository really isn't a factor.
So, if you are automatically, or at least very easily, doing a build-> deploy cycle with some tests, you're doing CI. The specific underlying products doesn't really matter.
However, yes, CI with BizTalk and TFS is easier because of the tooling.
Yes, it is perfectly feasible to use SVN for CI with BizTalk - I implemented such a solution back in 2008/9 using JetBrains TeamCity connected to SVN, utilising MSBuild scripts to perform the build, package and deployment to a test BizTalk environment. We then packaged the MSBuild scripts to perform the actual deploy to the various production environments.
If you're stuck with using SVN then I would seriously take a look at TeamCity (https://www.jetbrains.com/teamcity/) and use a Powershell Build Runner to build / deploy etc. your project - for a high-level overview on using PS in TeamCity, take a look at http://www.jokecamp.com/blog/tutorial-how-to-use-teamcity-powershell-runner-to-automatically-deploy-website/.
As for SVN, you seriously need to take a look at using a more modern, feature-rich and vulnerability-free VCS Take a look at using something a little more modern such as Visual Studio Online (i.e TFS in the cloud - https://www.visualstudio.com/en-us/products/visual-studio-team-services-vs.aspx) or Git (hosted through the myriad hosting providers, e.g. a private repo on https://github.com/)
Best of luck!
PS. I agree with #Johns-305 comments fully!
Related
You know, the next "big" and "enterprisey" thing from Microsoft.
Is it just me, or is it really hardly for humans? Main highlights are (IMO):
Absolutely cryptic syntax (-skip:objectName=filePath,absolutePath=App_Offline.* just for skipping App_Offline.html)
Manifest as an after thought
Lack of thorough documentation
Not a word about extensibility (except for several blog posts out there). Moreover, all these extensions developed in great pains have to be registered in GAC and registry
Waaay too low-level (metadata/metakey; all this IIS jazz)
No integration with MSBuild
Granted, MSDeploy and MSDeployAgent are quite powerful, but do they really need to be that complex for relatively simple tasks?
I too share your frustrations over the lack of documentation and the apparent low-level nature of this tool.
However what MS has done is finally create a free tool with which you can actually script whole server deployments, including parameterising addresses, configurations etc. This is unfortunately a very complicated thing to do - given how many bits of configuration actually go into a web server - and this is probably the best way to do it all.
What we need now is a really good GUI that can help build up these packages, and scripts etc. The GUI that is embedded within IIS is good - but again, short on explanation - so hopefully soon that'll be addressed.
On the functional side, I'm using at the moment to deploy a site from dev -> staging -> live with parameters to change bound IP addresses etc. I was deeply frustrated that it took me a few days to get it all working - however now I have it, I can remove a lot of the possibly of human error at the IT Support side - who are responsible for our deployments. I now only have the configuration of my master staging server to worry about - and can be sure that all the servers in the web farm will be kept in sync whenever I deploy.
As Sayed mentions, as well, there are MSBuild tasks in 2010 (the Website Deployment feature is now implemented using msdeploy) to work with this - which also brings the possibility of a true Continuous Integration environment to VSTeamSystem - having a team build that can actually perform a full web deployment as its last step is very exciting (and scary, granted!).
Actually there are MSBuild tasks for MSDeploy. They will be shipped with .NET 4/Visual Studio 2010.
Although a bit rough around the edges, I've come to like MSDeploy quite a bit. Using it to sync web servers in a farm is very useful as it is efficient (only copies changes) and takes care of actual IIS settings in addition to content files. It seems like MSDeploy is a building block for various scenarios and uses. Also, as previously mentioned, there is a MSBuild task for MSDeploy in .NET 4. I've taken advantage of this MSBuild task to make deployment of my web applications from TeamCity trivially easy. I've blogged here it here:
Web Deploy (MS Deploy) from TeamCity - http://www.geekytidbits.com/web-deploy-ms-deploy-from-teamcity/
I have recently started implementing a deployment pipeline and I found below links quite useful:
MSBuild commands I used for Continuous Integration:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html
WebDeploy sync commands, I used for deployment packages to production server:
http://sedodream.com/2012/08/20/WebDeployMSDeployHowToSyncAFolder.aspx
Also I used these references:
Video about MSBuild on dnrtv.com
Microsoft Press book called "Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build" which you can buy PDF version from Oreilly
Finally, "Continuous Delivery" book, gave me good ideas about deployment pipe line, although the book is not focusing on MSDeploy, but it is really worth reading.
The statement of documentation is typical of a MSFT 1.0 product, unfortunately MSDN no longer have dedicated Developer Technology Engineers to fill the gaps --- instead, there is a blind faith that the web will provide it.
I am actually considering dusting off my writing skills and write a short ebook on it since there is likely a market for it....
Msdeploy definitely has a touch of the PowerShell to it: power over simplicity rather than worse is better.
There is no Windows alternative to it, however you can hybridize some of its powers to make automated deployments. For example:
Compile your solution with Team City and msbuild
Use msdeploy to transform your site and web.configs on the build server
Manually FTP a ZIP file of your site (it doesn't support FTP)
Alternatively, use its remote deploy capabilities. This requires port 8172 open, lots of security changes and as far as I'm aware no concessions for load balancing
Use msdeploy on the live site to sync changes
As a tool it's clearly aimed at service providers as it's an enormous Swiss army knife. You can do all kinds of things to IIS with it, which for the most part are over kill for small businesses. I've no experience of large scale IIS setups so maybe that's where it shines.
At my company, we develop our ASP.NET applications as websites and often just work off of our network drive, which points directly to the files on our development web server. Our code is compiled at time of HTML request, so we don't build our web applications. I've read that automated builds are a best-practice, and aim to set that up as well at some point. Right now we're using VSS, which is awful, and I'd like to switch us to subversion.
I've read about NAnt for builds and deployment, and also just heard about CruiseControl.NET. Can I use these tools simply to push code from our SVN Repository to our development web server when a developer commits changes to it from their working copy?
You certainly can. I have gone through a very similar migration. We always compiled our web apps, but we migrated from VSS to SVN and then setup cruisecontrol and nant to automate our builds and deployments. We used to just drag and drop with windows explorer which was down right painful.
As it happens I have been blogging on this process. My last post specifically covers using cruisecontrol.net and NANT: http://www.mattwrock.com/post/2009/10/22/The-Perfect-Build-Part-3-Continuous-Integration-with-CruiseControlnet-and-NANT-for-Visual-Studio-Projects.aspx
I am CM/Developer at my company. We use Nant, CCNET and Subversion, for continous integration and automated deployments to the DEV servers. Works perfectly.
Things to note:
1. If your getting Nant, get Nant contrib as well
2. If your building and deploying installers, it will be easier to use devenv.exe to build the installers.
3. You can check out PSTools to install stuff on remote servers.
4. I would set up two different build categories in CCNEt, 1. for Continous and 2. For force builds....this should be your publish.
The set up can get pretty complex, I have used it with VSS as well, email me if you have any questions or need scripting help.
Yep.
At one company we built a nAnt script that did this. Very simple and effective, but extremely cryptic to change or update.
At another we used Cruise Control which worked great but again was a little cryptic (I think it uses nAnt on the backend), but was very nice to look at and see the steps and problems visually.
Honestly though, the latest Team Server from MS is very good at managing code and very nice at producing builds as well. By far the easiest and effective way I've ever used to deploy .net code.
95% of my time I program ASP.NET (MVC) web sites.
Should I care about MSBuild?
We use MSBuild with CruiseControl.Net to manage the builds of most of our big ASP.NET projects. For every commit of one member of the team, a build is launched. It helps us detect
quickely incompatibilities before moving a feature to "staging" or "production".
I think it is really usefull when working with a team on the same ASP.NET project or if you are working alone on a big project.
That depends on your development environment.
If you have other folks that do deployment of your systems, and they take care of the build and deployment environment, then MSBuild probably won't be necessary for your work.
On the other hand, if you need to configure the build script to understand special situations that your code comes up with, then you will definitely need to understand MSBuild scripts.
Even for a one-man shop, it's a useful tool to know, especially if you are configuring a continuous integration server like Hudson.
No. Until you have to.
Its not absolutely necessary to know MS Build, but it is useful to know.
It might not be needed for all kind of projects, but it is extremely useful when you are working on a huge code base with automated custom build solution/ nightly build/developer builds so on and so forth.
It's unlikely, unless you choose to use it, or you start to make use of Team Foundation Server's Team Build.
Your development processes need to get to a certain complexity before automated builds really deliver their true value and/or if you find need for automatic deployment (including database changes if applicable).
The coming Visual Studio 2010 is going to make it far easier to use, but for now it retains a fairly steep learning curve which you can avoid by using alternatives, or commercial products (e.g. Visual Build Pro, Final Builder etc).
The nice thing is that it is part of the .Net framework, so it's already available as long as you have the framework installed (which it probably is).
So, in short, not really. It's something very useful and powerful though, setting up deployments using MSBuild can be very, very useful.
What should a developer know about MsBuild?
Every developer should know it exists and it's basic capabilities. If know it exists you won't duplicate its features and will know what it can do for you, when you need it.
Minimum:
As an exercise, build your project through the command line: msbuild myproj.sln
Know the role of continuous integration
A little more than minimum:
Hack your csproj (or vbproj) with a message task, so it outputs something during clean.
All done. When you need to know more, you'll figure it out.
I'm working on transitioning my current project of about 20 developers to a modern development and build environment. We currently use an RCS based source control system and an associated issue tracking system, both with Motif UIs. There is no formal production build process, its just whatever works.
I'm interested in:
Development Tools
Version Control
Issue Tracking
Dependency Management
Configuration Management
Automated Building
Automated Testing
Continuous Integration
Artifact Management
Release Management
Deployment Management
Requirements Tracing
What else?
I'm interested in not just which tools you use, but how well the integrate with each other, how easy they are to setup and use, and how both developers and management likes them. Our project is a combination of Java, C++, and VHDL, but I'd still like to hear from people with other languages. I'm currently going down the path of eclipse, subversion, trac, maven, hudson, and nexus.
Also, is there a better term than "Build Lifecycle" that encompasses not just building, but the flow of code from when the developer creates it to when its built, tested, and in a production system? "Build Lifecycle" seems limited, but "Project Lifecycle" is already taken.
I hate Maven less than I hate Ant, and for Java, you need to choose one of those evils. If you're just starting out, choose Maven, especially since you've already recognized that your "build lifecycle" encompasses 12 different and complex disciplines! You're going to have to choose conventions for all of them. Save yourself the trouble and go with the conventions Maven has already established.
For continuous integration and general build automation, I like Hudson.
During the last two years we gradually switched from a "every-project-has-its-own-toolset" strategy to a Trac+SVN+SCons solution and are quite happy with that.
Switching to SCons was a bit of work but really paid off. We have a heterogeneous environment, mostly C/C++ for different embedded platforms, kernel modules, some desktop applications and various Python modules as glue code. SCons really shines when you want to add support for your own compilers and niche-tools and need to adapt the build system to your requirements. Formerly, we had to use a different GUI for almost every embedded platform - now that SCons directly invokes the compilers the work-cycle has slightly improved.
Our developers either used Emacs or Vim and no one wanted to switch to anything else, so we (fortunately) sticked with that. I'm not very familiar with deployment so I can't talk about that.
If you work with .NET, it's hard to beat Team Foundation Server for its integration with Visual Studio. It contains the development tools, version control, issue tracking, configuration management, automated testing, unit testing, automated building, artifact management and everything else you've described.
Of course, TFS is expensive, oftentimes non-intuitive and is missing some features compared to other tools I've used. If you have a MSDN license you can use TFS for Workgroups (up to 5 users IIRC) for free, though.
Development Tools JetBrains IntelliJ IDEA
Version Control Subversion
Issue Tracking Atlassian Jira
Dependency Management Maven
Configuration Management TeamCity
Automated Building TeamCity
Automated Testing JUnit(?)
Continuous Integration TeamCity
Artifact Management Maven
Release Management Homo Sapien
Deployment Management Maven/Homo Sapien
Requirements Tracing Wishful thinking
One-Off Automation Bash
Developer-to-Developer Documentation MediaWiki
We're an MS shop using VS2008. We use Subversion with Tortoise for SCC and versioning, and our repository is hosted online so our distibuted team can use it. For build we're using Hudson and CI, much better than Nant or MSBuild. Issue tracking is Bugzilla. Automated testing is NUnit
Tools to avoid include Team Foundation Server and Sharepoint, too clunky for real world usage.
BTW Does anyone know a good Scrum tool, which can produce burn down charts, ideally linking into Basecamp?
We also use a number of tools, but we're moving more and more to Zed Builds & Bugs. Our primary dev environment is Eclipse + Java, but we also do Visual Studio (all of 'em), and at least 5 different unix platform builds.
Here's the full list:
Development Tools - Eclipse
Version Control - Subversion
Issue Tracking - Zed Builds & Bugs
Dependency Management - Ant
Configuration Management - Zed Builds & Bugs
Automated Building - Zed Builds & Bugs
Automated Testing - JUnit
Continuous Integration - Zed Builds & Bugs
Artifact Management - Zed Builds & Bugs
Release Management - Zed Builds & Bugs
Deployment Management - Zed Builds & Bugs
Requirements Tracing - Zed Builds & Bugs
One-Off Automation - Zed Builds & Bugs
Developer-to-Developer - Zed Builds & Bugs
I use svn and tac on some oof my projects and svn and fogbugz on others. They integrate very well.
I am still using command line scripts for builds as they do everything I need - including grepping for errors and emailing results, but the days of that setup are numbered. I am looking into cross-platform build tools.
I use Inno for win32 releases. No shipping products yet for other platform - not sure how we'll deploy those.
We don't address a lot of the other items you mention other than on some ancillary documentation and in the code and in issue tracking.
Team Foundation Server and Visual Studio.
I remember when my ide was Sun's visual C debugger, and source control was copying all source files to a new named directory and putting it on a server that was supposed to be backed up.
Only it wasn't
What to do automatic nightly build of .NET web application and upload to the test server.
Or, if this tool is overkill, please suggest something else.
I have found this great tutorial: How to Hook Up a VS.NET 2005 Solution With CruiseControl.NET in a Few Minutes.
It's short but uses a real .Net project to illustrate the set up.
After that refine your configuration by reading each relevant section of CruiseControl.NET : Configuring the Server
And for a really nice and recent tutorial check Integrating MSBuild with CruiseControl.NET. Very good one!
The other answers are all great, but have you also looked at CI Factory? From the CI Factory site:
CI Factory is a Continuous Integration
system, not just a CI server. With
minimal configuration it creates a CI
system for you including much of your
development environment. It will
create a development tree, write your
build scripts, setup a super powered
version of CruiseControl.Net, import
it all into source control, and more.
It does all the work that everyone has
to do when creating a CI system. It
even has automated branch creation
baked in, so the next time you need to
create a branch for a release, CI
Factory will handle that for you.
CruiseControl.NET From Scratch
Its a great tool, we use it here todo hourly builds and manage multiple projects.
I used the instructions and example on the CruiseControl.Net website
Setting up from scratch Part 01.