In our development environment each developer has their own dev server. Often times they do not actually develop on that server but develop from their local machine, deploy to their dev server, and then attach with the remote debugger to do debugging.
My question is; how can I use MSBuild to execute a different set of tasks for each user?
I want to enable each user to define their own build process with MSBuild tasks but I don't want that to necessarily affect the other developers. I also want a default set of tasks to execute if a given user explicitly defined their own process.
Example:
SomeProj.csproj
Default MS Build process is to copy to test server or staging server
Custom process for Steve is to copy to Steve's dev server
Custom process for Eric is to copy to Eric's dev server
You could use the project user file (*.suo / *.user) to do some 'poor mans dependency injection'.
looks like this guy did something similar
Yeah, I've done this before. Try trick is to key off $(USERNAME) in your msbuild script. If you haven't tried editing msbuild scripts before, you've got a lot of learning to do.
Related
I have a doubt.
How can i create scritps to :
Get my code from repository (GitHub, GitLab...)
Build
Publish
Test
Run in IIS
This script should run in windows or linux OS, and consider that i have a empty VM.
This application is an .Net Core WebApi.
I searched in web but not found an template geting code from repository.
This is doable with scripts like #Scott said and you should consider using solutions for this because there are some great free ones out there like teamcity with octopus integration. Here is what you need to consider if you decide on making scripts for this.
The vm you have is empty so the runtimes need to be installed and
checked are they compatible with code you are trying to deploy to
them.
The scripts for some parts of deployment will need to be run under user with sufficient privileges
You will need to handle the webserver configuration with the scripts as well for all of this
And those only a few things that are on the list for that path. Now having said that there is the path of containers which handle most of this through code and can be deployed to all of environments you mentioned before and you only need to worry that there is a container service on those vm-s you want to deploy to and it will be much easier to handle since like i mentioned it is all in code and is easily changed unlike some scripts.
We have one TeamCity server running on a mac, we have multiple agents running on mac and windows that do different types of builds.
Although the builds themselves are different (build with xcode/build with msbuild), there are a bunch of scripts at the end of each configuration that are the same. They involve copying files to a specific network share, notifying team members, and a few other things.
What would be great is if I could run the platform specific tasks on the respective build agent, but have the actual server run the final scripts after that.
The reason for this is to avoid writing everything in both bash and batch files (I can write it for the server, and make sure it has any dependancies), but also if we wanted to hook up an audio/visual/physical alert for a build fail, the script that runs that should only run on the server (no speakers/lights/nerf cannon on the agents).
Any ideas how I can easily setup a script to run on the server itself, and pass in the properties from the build?
Does this require a plugin, can I do something with the dependancy system, or do I need to delve into the REST API and trigger other configurations that way?
The solution we came to in the end was to use Meta-runners with a Python Runner. This allows us to have cross-platform python scripts that we can setup using the Team City variables. It also allows us to use these scripts in multiple configurations.
If anyone is looking to do this themselves, the platform module in python is useful if you still need to do some platform specific things in your script.
For example the following code allows us to us to use network share paths already setup on the build agents:
if platform.system() == 'Windows':
network_folder = "//server_pc/builds"
else:
network_folder = "/Volumes/builds"
I'm packaging up some mongo scripts along with the necessary binaries to run them into a Nuget package via Teamcity. Now what I want to do with Octopus is pull that package, extract the contents and run the scripts once per deployment. I don't want or need these to be deployed to any machines as these scripts are not target machine specific. I was thinking via powershell I could
Download the package (possibly query the feed for a specific version)
Extract it
Run the scripts
Clean up
Anyone experienced a similar problem?
The solution is to install a Tentacle on the Octopus Server, assign it to all environments, give it a unique role along the lines of octopus-server, and then configure a script step to use the octopus-server role as your target. You can then write a PowerShell, C# or Bash script in that script step that will call and execute the mongo scripts that you have stored in your project. That way, it'll only run on your Octopus Server. I've done something similar to run MySQL scripts recently.
The OctopusDeploy docs provide a nice walkthrough here and an explanation of why they chose to handle it that way.
In my CruiseControl instances, I have version controlled the ccnet.config file.
When I want to update CruiseControl, I run an "update config" job which fetches the config from version control.
In this manner, the very build process of a release is configuration managed.
I am wondering how to achieve these goals effectively under TeamCity.
I try to keep what ever CI I am using as light as possible and put as much of the running of the build into an msbuild or nant script including running tests, code coverage, etc.
The benefit of this is:
The build file is version controlled.
You can run the script in any environment.
Easier to move between CI environments.
Everyone becomes responsible for the build.
This has been introduced in TeamCity 9. Also answered in another post:
Version control (e.g. in TFS) build configuration for TeamCity - is it possible?
I've been wanting a way to source control TeamCity config for a long time. I ended up writing a Windows Service which monitors the configuration directory and commits changes to git.
The project is on GitHub: https://github.com/grenade/teamcity-config-monitor
You might try looking at the folders that are backed up prior to upgrade (or when restoring team city) as those represent the configurations and changes you've made since initial installation.
http://confluence.jetbrains.net/display/TCD4/TeamCity+Data+Backup
Some of the relevant data is actually a database, (and in fact the documentation advises you to point team city to a real database like mysql instead of the default embedded database it uses)
You could try checking those into SVN, but you'll want to stop team city for any check-in actions.
I've just installed Hudson and it is running beautifully. It builds, runs JUnit-tests and also CheckStyle analysis.
Next step for us would be to create an installation, install it and then run automated tests on the actual installation. I would then like to fail the build if the tests fail or at least publish the results somehow. I think we would set it up so that part runs periodically or manually triggered.
We use InstallAnywhere for installation and IBM Rational Functional Tester for automated tests.
So questions are: anyone created a similar setup? are there any plugins, tutorials or other resource that could help me along. Or do you have any tips or advice in general.
The command line reference for Rational Functional Tester:
http://publib.boulder.ibm.com/infocenter/rfthelp/v8r0m0/index.jsp?topic=/com.ibm.rational.test.ft.doc/topics/RobotJCommandLine.html
Sample command for running a test:
java -classpath "C:\IBM\RFT\FunctionalTester\bin\rational_ft.jar"
com.rational.test.ft.rational_ft -datastore \\My_project\AUser\RobotJProjects -user admin -project
\\My_project\AUser\TestManagerProjects\Test.rsp -build "Build 1" -logfolder "Default" -log
"Al_SimpleClassicsA#1" -rt.log_format "TestManager" -rt.bring_up_logviewer true -playback
basetests.SimpleClassicsA_01
An additional note, you'll want to configure windows properly on your agent machine which will be running the tests. This is not advice specific to Hudson or RFT, but rather all GUI automation tools on Windows. RFT will require an interactive desktop environment for it to be able to click buttons, etc. If you have your Hudson agent running as a Windows service, there will be no desktop. See the following: Silverlight tests not working unless RDP connection open
We have run a fairly complicated distributed build on Hudson, it is a process that basically follows:
Test on Windows.
Test on OSX, run code coverage & push results to server.
Test on OSX Tiger.
Package for OSX Leopard & push build to server.
Package for Windows & push build to server.
Update product website.
We don't use InstallAnywhere or Rational Functional Tester, but have similar sorts of mechanisms in their place. The key we found to making it all sing in Hudson was being able run our various steps from the command line. Maven and appropriate plugins made short work of this task. So my advice would be just that, using whatever build tool you are using (ant, maven, ?) configure them so that you can run your rational functional tester and install anywhere from the command line with a simple goal passed to your build tool (i.e. mvn test or mvn assembly:assembly).
After that, make sure whatever machine Hudson is running on has everything installed (i.e. Rational Functional Tester) and configured, so that you can open up the command line and type in the goal and have your tests correctly execute.
Hooking it up in Hudson from that point on is fairly simple - just pass in the goal when you configure the build.
I believe the best answer is that integrating RFT with Hudson/Jenkins is a useless endeavor.
As this IBM FAQ says, to make RFT work you must:
be logged in the machine;
the screen can't be locked;
if you are remotely connected, you can't minimize the connection screen.
So you can't run Jenkins/Hudson as a service, making it not very useful. You must run it from your logged account. If you are in a corporate computer (very probable if you are using RFT), you probably must use a hack to prevent the screen saver to start. If the screen is locked, your tests will always fails.
It isn't very difficult to configure your tests to run from the command line, you just have to take care of the return codes when the tests fail and succeed.
Jenkins/Hudson would also give you some advantages, like integrating the tests with your version control, probably automatically running the tests when a commit is made. It would also help sending emails when the tests fail.
But you still would have to integrate the RFT logs with some kind of JUnit plugin to have a nice report. You also would have to have script to run the tests using the command line.
I think it is not worth the trouble to use an continuous integration server with RFT. Better just have your tests running every day in Windows Task Scheduler. It is a simpler solution with less failure points.
Or use my final solution: quit RFT and use the free Selenium with a headless web driver.
I have some general advice on this because I have not yet implemented this myself.
I am assuming you want to have Hudson run the RFT scripts automatically for you via a build or Hudson process?
I want to implement something similar in my organisation as well.
I have not yet been able to implement this because of organisational constraints but here is what I have thought out/done so far:
Downloaded Windows process viewer, got the command for running the tests.
Made shell Script out of it, separated out the variables etc
The future plan is to setup a Windows Slave machine which would have all the tools in it that would be required once the Tests are kicked off, for eg. the correct versions of browsers, and environment variables, and other tools that are required.
Hudson would kick off a process which runs the shell scripts created which runs all the RFT Scripts and performs necessary operations on the slave machine.