Quick question: If I were to set up my build server to publish to a test environment after every check-in, wouldn't that constantly interrupt the testers if the ASP.Net site they are testing would come down periodically as developers check in their changes?
We are looking to ensure the bugs we have marked as resolved are always available for testing, but we also don't want our testers to have the site come down in the middle of their tests.
Thanks!
Chris
My suggestion is to have a dedicated environment for each tester (TFS Lab is a great way to achieve this). Then allow each tester to manually kick off a build that updates their environment with the latest build whenever they desire.
If you must do a shared test environment, then I suggest not updating every build for specifically this reason, but instead doing a nightly build that updates it (and/or using a manual build that testers can run on demand).
Related
We've got a project with a test, dev and production release. The test and production releases are set to manual. I want to manually run the release, but don't know how to do that unless I edit the release, change the environment variables from "No automated deployment" to either "After release creation" or "After successful deployment on another environment", then run the build. Then change it all back again. The build makes all of the artifacts available, for all of the releases.
But I figure there must be a way of running the manually release, manually. I just can't find how nor where to do that in TFS's web interface. How do I do this? (Please forgive me if I've stated something wrong. Hopefully, I've made myself clear.)
We're using TFS 2015, on-premise.
Once you create a release, open it up. The release has a "Deploy" button. Clicking that will show you a list of the available environments, and you can choose one to deploy.
I don't have an instance of TFS 2015 readily available otherwise I'd post a screenshot. Here's a screenshot showing the general location of the Deploy button from Microsoft's documentation:
What I need Actually?
We create the iPhone application for Mobile & iPad and the code is always checked in to the repository.
1) When ever the code is checked in to the code repository, that has to under go the automation testing and confirm the build does not failed or the app itself will works as per teh functional test scripts.
2) If there is any Build failure, mail has to be triggered to the developers.
3) The build is sucess and automation scripts are executed and that is also passed, next step is to deploy to the apple store and submit for review, necessary information for apple store is made available in configuration files.
Existing reference in stack overflow:
Continuous Integration for Xcode projects?
**Reference**: http://stackoverflow.com/questions/212999/continuous-integration-for-xcode-projects/17097018#17097018
Continuous integration for iphone xcode
**Reference**: http://stackoverflow.com/questions/1544119/continous-integration-for-iphone-xcode
Some of other references also was checked, which just give me the idea of how to execute functional script during code checkin, which is actual works like any CI tools likes Jenkins etc.
Above said reference are also discussed during 2009/2013, which are evry old.
What is available when researched?
I came to know about using using Hudson on the mac, which is very old version and not much supportive and also found Xcode OS X Server which is a product of apple itself where the reviews are not good and implementation is not feasible for my requirement.
Please share me the the approach of how to achieve this, also is that is possible to do CI process a one touch go for IOS, I found something similar to android with few confirmation from user.
At-least execution of Tests and creating an .ipa file in ios will be great.
I am currently using Jenkins on an independent server for iOS continuous integration. Jenkins builds, tests, and creates HTML links so the app can be downloaded from ad-hoc devices (Continuous Delivery).
Whenever I make an App Store release I get the code of the build I want and I make a build out of it. This presents a problem, since the although the code is the same, the binary is not guaranteed to be the same since two different machines are involved.
You usually read that in continuous integration releases should be a non-event. This works for me for the everyday builds but, what is the best approach to make App Store releases in a continuous integration environment?
I ended up adding a new job in Jenkins which only builds an .xcodearchive. That job belongs to a pipeline and is the last task to be executed. The command used to build the archive is:
xcodebuild -scheme ${JK_SCHEMA_NAME} -archivePath ${JK_OUTPUT_DIR}/${JK_ARCHIVE_NAME} clean archive "CODE_SIGN_IDENTITY=${JK_CODE_SIGN_IDENTITY}" "GCC_PREPROCESSOR_DEFINITIONS=${GCC_PREPROCESSOR_DEFINITIONS} ${JK_GCC_PREPROCESSOR_DEFINITIONS}" "PROVISIONING_PROFILE=${JK_PROVISIONING_PROFILE_UDID}"
This way I can make sure the flow to deliver an app from commit to final binary for the store is completely automated (or at least doesn't need human interaction). The version numbers are correctly set, and that there are no changes in source code or compiling options that can alter the final archive uploaded to the store.
So, we're using continuous integration in our current Team Foundation Server 2010 setup, and so far it's working great. We're doing shelvesets, the build is running on the Build Manager in TFS, and it's also running our MSTest unit tests for us.
My question is, and I can't seem to find any information on this, is how to move the "build unit" that is created by the Build Manager on TFS to another server?
Aka, how do I "promote" this build to our QA, staging, etc... environments?
Before, we've were using VS2010's Publish Web feature, which allows us to set up publish "profiles", and each profile can have a different web.config related to it. This is really useful for anything we keep in our config files, like db connection strings, paths to app servers, etc... changing automatically based on our Publish Profile. We choose the profile, build locally, then use the "Publish" button to move the entire app to another server.
This setup worked great for when there were two of us working, and we were using TFS for just its source repository, but now the builds are happening on the TFS server.
What I'm looking for is a way for when TFS does the build for us (it's no longer being done locally on our machine, but by TFS Build Manager) to:
take into account which "publish profile" to use. This will effect what web.config is used and other items you can associate with a profile in your IDE.
once the build is created, to find a way to "push" the build to one of our other servers (QA, Staging, production) FROM TFS.
I don't even know if that is possible or not. Maybe it's still a manual job to take the build created on TFS, and copy it over by hand, and unzip the project/files into the correct file path on the deployed server? Or maybe it's part of the workflow in TFS, and I still have yet to find it.
This is surely possible already from TFS. Read the posts from Vishal Joshi on this topic, starting with: http://vishaljoshi.blogspot.com/2011/07/documenting-key-end-to-end-deployment.html
The solution I came up with is I wrote my own build handler for TFS, and use that code to push builds to our different environments. Here is the link I used to help me: http://geekswithblogs.net/jakob/archive/2010/10/27/devleoping-and-debugging-server-side-event-handlers-in-tfs-2010.aspx.
If anyone wants more specifics, just contact me and I'll be glad to help you.
This seems like it should be obvious so maybe I am not understanding something. I have TFS setup. My web apps code is in source control. I can check-in/out and create builds but I don't quite understand what the recommended method for publishing the code to the production environment is? I was looking for something like "publish release to web server" but can't find anything. I think my larger problem is that I can't find a good work-flow diagram for how a team is supposed to move from editing code to testing and then to deploying to the production servers all within the TFS system. If anyone has any thoughts or links to good walkthroughs on publishing a website from within TFS that would be fantastic.
For the workflow I would suggest the code promotion model.
Within TFS you have the idea of build quality. SO when you initially check code in the build will kick off with a quality of say "ready for test" if the build passes the testers can decide when they want to take a build for testing, when they have tested a build they can mark it as "ready for deployment", you can then use that realeas to deploy.
Unless things have changed in TFS 2010 you have to roll your own implementation for deployment. We used MS build to build MSIs using Wix, then had the testers test the deployment process for us.
Have a look at the following msbuild extensions to help with deploying to test/live environments:
http://msbuildtasks.tigris.org/
http://msbuildextensionpack.codeplex.com/
I would really recommend you spend a little time on your build process and get it water tight, there is nothing more embarrassing that deploying a release to live that doesn't work and the client loosing faith over it.
I don't believe there is a built-in mechanism in Team Build to publish websites, however this can be achieved by overriding AfterDropBuild or AfterEndToEndIteration in your build definition to include necessary tasks for copying the build output to your web servers.