I would like to have my app rebuilt and redeployed once per day. The reason for this is that I am using Jekyll and I display 'upcoming events'. I use LiquidScript to determine which events are 'upcoming', which ones are already in the past and which ones are too far in the future. But without redeploying, nothing on the site changes, even if I rebuild it. That's why I would like a solution to this, and one that can be made automatic with scheduler.
Related
We've recently launched a new website in Azure (i.e. Azure Websites) and as is typical with new launches we've had to deploy a few tweaks to fix minor issues shortly after launch.
We want to use Slots in the long run but this is not possible at the moment. Hence we are deploying to the live site. It's a fairly busy site with a good amount of traffic and obviously want to keep downtime to am minimum.
We are using Visual Studio to publish file changes to Azure but have noticed that even if we publish a relatively insignificant single file the whole site goes down and struggles to come back up. I was assuming that publishing a single file would literally just replace that file on the file system but it's behaving more like it recycles the application pool (or Azure equivalent) for the site. The type of files I've been publishing have been Razor views, hence would not typically cause a recycle.
Does anyone know what actually happens under the hood of VS Publish and if there is a way to avoid this happening?
Thanks.
I just tried this using a basically clean new MVC app (https://github.com/KuduApps/Dev14_Net46_Mvc5), and I did not see this behavior. The Index.html view has a hit count based on a static, which would tell us if the app or the page got restarted (or if that specific page got recompiled).
Then the test is to publish it, make a change to some other view (about.cshtml), and publish again. WHen doing this and hitting Index.cshtml, the count keeps going up, and there is minimal slowdown.
If you see it getting restarted after a view change, I suggest using Kudu Console to look at the files in site\wwwroot before/after the publish, and check what has a newer timestamp (e.g. check web.config, bin folder, ...).
We are using Microsoft Team foundation server for version control where multiple developers are working on a branch and check in and check out the code.
How can a developer A be notified via email or SMS that his code got overwritten during the checkin by developer B.
Developer A needs to know this ASAP because the code changes of developer A will not work when its deployed into QA.
We are tring to save time in a fast paced development environment and trying to avoid code overwrite issues.
The easiest way to allow continuous parallel development and prevent a checkin from one person breaking the code of others, is to use a CI server. TFS supports this through Team Build.
Though it's preferred to run team build on a dedicated build server, it can be installed side-by-side on your main TFS server and it's possible to install the Controller component centrally and use your developer's workstations as agents.
There are two types of build triggers that can help you out here:
Continuous Integration - this triggers a build of all code directly after every checkin. It will tell you quickly that something did not compile. If you are doing unit tests it can even run these and tell you that a test is failing.
Gated - this will force a developer to shelve his code and will only check in the code when the build of the latest version plus the changes in the shelveset succeed. This may seem even better, as the code in source control will never be in a broken state, but in reality I prefer the ci trigger. The main reason for that us that Gated builds can't happen in parallel (due to their nature) and can actually delay the notification that the code is broken.
You can easily configure email alerts through webaccess on specific build outcomes. You can also configure alerts on source changes, but there is no option to only warn people who have edited these specific files before.
You can also run the Build Notification tool from the task tray to show a notification in Windows.
Though this will not tell the person whose code has just been overwritten that it's no longer working, it will tell the person I rewriting that code that he should pay more attention when checking in ;).
Of course you can configure a team alert that notifies everyone when the build breaks (as that's generally called), and there are funny ways to show the build status through small apps like "siren of shame", which provides a build monitor service that can be connected to a USB alarm-light that turns on and provides noise whenever someone does something stupid.
If you need to avoid this problem during check-in & merge, then I would recommend disabling multiple check-out. This allows file to only be checked out one-at-a-time and can prevent confusion on team projects.
If you need to do farther down the line, you can create TFS Alerts when any code is checked in and sent out to a distribution list, but it would not notify when specific contributions from a specific developer is altered - only a list of altered files during the check-in.
I've been working on using Xcode server to build my app, and have been running into some snags. The most recent involves Bots running over-zealously. I'll commit and push one change to one file, and two builds get triggered, separated by a minute or two. This also happens if I click the "Integrate Now" button, or if I make changes to the bot, with "Integrate immediately" unchecked.
Since my build takes a while to run, this is a pretty big problem, especially when I'm trying to iterate on Bot configuration.
Is anyone aware of what process triggers builds, or how can I troubleshoot this type of failure in general? It seems like there are multiple daemons listening for the signal to trigger the build or something like that.
Since it may be a bug in the Xcode beta, I submitted a radar (rdar://20456212)
I had the same problem. I changed the bot so that it does not do a clean for each integration and now it only does one build per commit. My guess is that the clean process and download of code was taking so long that the bot was being triggered before it was complete. So now I clean once a day and I only get a double build on the first build of the day. Hope this helps.
I want to migrate from star team 2005 to TFS 2010 with HISTORY. Is there any tool or any way where I can do it cost effectively. I know about Timely Migration tool, but it is too expensive.
There is no tool out there to do this. You are stuck with paying for Timely Migration or writing it yourself. Capturing history from StarTeam is extremely complex. The reason for this is because of what the view looks like historically. You can roll back the view to a point in time, and this alone works very well, but rolling back to every point in time where a change happened to the view is practically impossible to do using the API. This is because 1) not everything has an Audit record, so you can't use the audits, and 2) the audit records are purged, 3) there is a special feature to "play back" the history of the view to generate the listener events (requires MPX), but this will miss many events, 4) when items are shared, configured, branched, etc., these do not generate any audits in the project, 5) even if they did, getting every single change requires iterating through the view history down to the second to get all of the changes by analyzing the differences. So that means if your project has been active for a month and each time you analyze the two view configurations to diff them it takes 5 seconds, then actually migrating your project would take 5 months, and in the meantime it would be locked down.
So the next way to do this would be to establish "baselines" to compare. Using build labels is a good starting point if you have nightly or continuous builds in your project, or even just certain builds that were QA certified. This way you can use these baselines as points for diff/compare and then bring in the history that way. While this isn't as granular as a full history, it is by definition getting the most important differences to migrate over.
However, keep in mind that even doing it this way does not maintain the links between branch/merge points across the different branches/views. The only way to do this would be to go directly into the StarTeam database to get this information.
I went through all of these steps to try and write my own suite of tools to migrate from StarTeam to Subversion. It was fun and interesting and imperfect but had some promise, but ultimately never finished it. Part of the reason was because the time involved would have been far more than the value I got from it.
Which brings you inevitably to the most important question: what is the business value of maintaining full history? After going through this many times with project teams as a StarTeam administrator, more than 90% of the time it was readily apparent that the better approach is a cut-over. Make a time where you can begin working on new work in the new system and freeze work in the old system. It usually can be done with very little down time for the project team. You can even start by bringing over a history of Production releases to create a rough timeline in the new system. Use your existing comparison tools, either in TFS or BeyondCompare or elsewhere, to reproduce each state of your project source code, doc, etc. and reconcile it with your TFS project by checking in or deleting files as needed, and labeling your TFS project for each build you bring over. Line up all your TFS builds, work items, users, roles, etc, and make sure everything is ready. Then at time of cut-over, take the latest development snapshot from StarTeam over and do one more update to your TFS project. Lock your Starteam users out of the project (for checkins anyway), and begin working in TFS. Your TFS project will have a rough history of the most significant baselines and you will be able to keep your StarTeam repository open to users in case more history is needed.
One other thing to consider is how to create a permanent archive of your project. If your repository is small enough it is doable, but gets more time intensive the larger your project is. First, copy your entire database and vault to a separate instance and get that copy up and running. Then delete all other projects EXCEPT the projects you want to archive off. Run an online purge and make sure to run it to completion. You may need to restart your server and purge several times. When you are done, your entire repository should contain only the files and database records that are needed by your project. At this point you can back up your database and vault and keep them indefinitely. This reduces the size of your existing StarTeam repository.
Haven't used StarTeam in over 3 years but that was a fun ride back in time. Hope you found it useful.
I'm trying to work out an automated Build-Deploy-Test workflow using Lab Management/VS 2010 and everything is working ok... except for one small thing.
In my build definition, within the process>environment I set a snapshot that I want the environment to be reverted to before deploying, and this works fine, but when the snapshot is reverted to, the environment is stopped but not restarted.
What results is that the build waits indefinitely for the workflow capability to be available on the environment.
A temporary fix is to just watch and wait for the enivonment to be stopped, and then to start it manually and everything will proceed as expected... but this is hardly ideal.
This is happening to everyone on my team, and none of us have come across a solution. Has anyone else seen this and solved it?
You'll want to take the "Initial Snapshot" when the VM is actually turned on. You can do that, or you can customize the Lab default build process template and include a StartEnvironment workflow activity after the restore snapshot phase.
My suggestion would be to just take the snapshot when the VMs are turned on though. That's the way I have always ended up doing it.