What are the best practices and options for expanding to a small team ?
I am the only user of Visual Studio 2012 in my small company. I am using Visual Studio Online for Source Control (as I understand it, this exposes Microsoft Visual Studio Team Foundation Server Version Version 14.0.12345.23456 as a "service" (i.e. this is the cloud...there is no on-premise TFS installed). Currently, I am using a LOCAL workspace (the default) and TFVC (not GIT).
My development server runs IIS 7.5 on Win2008 R2. I logon locally to this dev server and launch VStudio 2012 Professional as an administrator. Project source code is on the local harddrive (e.g. d:\projects\projectA, etc.). I can interactively debug my web application projects and sit on a breakpoint without "disturbing" any other user or developer.
I work remotely so I use a mobile VPN with SSL to connect via Remote Desktop to the above development server (only 2 concurrent connections are supported now).
Some specific questions:
Can another person(s) somehow "share" the above environment?
How can developer2 and dev3 work concurrently on same project(s) as me?
Can I simply add dev2 and dev3 logons to the admin group on the dev server?
Would changing the TFS setting from LOCAL workspace to SERVER workspace enable team development (i.e. prevent checkout if already checked out, etc.)
If "sharing" the above environment is possible, what would the ideal arrangement look like (e.g. each developer has own server, own Vstudio license, etc.)?
Usually, every developer in a team has their own development machine. You create a team project in Visual Studio Online, and check in your project to this team project. When you want to dev2 and dev3 to work on this project, you can add dev2 and dev3 in the team project (Visual Studio Online provides 5 free licenses), so they can access this team project and get the project to their development machine.
Team Foundation Version Control is a centralized version control system. Typically, team members have only one version of each file on their dev machines. Historical data is maintained only on the server. Every time your team checks in their work into Visual Studio Online, you can easily audit changes and identify which user checked in a changeset.
Regarding Workspace, please check the definitions below:
•Server workspaces: Before making changes, team members publicly check
out files. Most operations require developers to be connected to the
server. (In the past teams blocked more than one person from checking
out, but this is now less common.) This system facilitates locking
work flows.
•Local workspaces: Each team member takes a copy of the
latest version of the codebase with them and works offline as needed.
Developers check in their changes and resolve conflicts as necessary.
Usually, local workspace is recommended.
More information of TFVC, you can refer to https://msdn.microsoft.com/en-us/library/ms181237%28v=vs.140%29.aspx
Related
I have now a working Website that I have deployed to the IIS on my local machine using Visual Studio 2013. I can access the website successfully from other machines in my office and in neighboring offices. I have even had others check the access from geographically remote locations, and still been successful. The access method is to put my machine's IP Address and add the name of the application, ###.###.###.###\name, into the address bar of a browser.
The next step is to promote it to production. We are not using Azure, so the tutorials for promotion to production I have found aren't useful, nor are we using 3rd party providers.
The method I have conceived is as follows:
Have an admin directly login into a company server
install the database software
install Visual Studio
install IIS
copy the local machine's db to the server db
copy the locally deployed files to the server
admin login into Visual Studio
deploy the site on the server in the same way it was deployed on the local machine
use the server IP or update the host file on all networked computers to map the IP to an appropriate name (or the local network has a local DNS we can update)
This would allow me a DEV environment (the VS IDE), a TEST env (locally deployed version), and a PROD env (the version deployed on the server).
I don't see any reasons why this wouldn't work, maybe a bit tedious, but workable.
Is this method ok? Am I missing anything critical?
No, this is an altogether inappropriate way to push a build to a production environment.
Your source code should be stored in a source code repository. You should have an automated, continuous build server pull from the repository and complete the build in a dedicated environment that is itself under change control. The build should include the generation of installation files, e.g. a click-once deployment package. From there you can have an admin run the deployment package, or, ideally, you'd push it automatically with a tool like Octopus.
The above, honestly, is the bare minimum for a commercial web site. There is much, much more you can do to make things even more robust, e.g. blue-green deployment.
Note that none of this involves installing development tools like Visual Studio on your server. The server should stay as clean as possible, running the fewest applications that you need, to minimize any sort of attack surface and to keep the machine running efficiently.
Dont Put Yours Machine IP, Decompilers Can Take It And BruteForce Your IP To Remote Acess Your Machine.
For web application package vendors providing installer for some reason:
Would you share the "standard" approach to prepare fixed server environment for an asp.net application package? But some conditions I have:
1)My application requires iis, .net framework and sql server.
2)Windows Server itself, Sql Server licence and media is not provided by my company, end users provide them.(Usually standard edition.) When visiting end user site, Windows Os is already installed, but SQLserver media is not.
3)Install paths of sqlserver program, datas(mdf, ldf) can be changed by users according to server condition.
4)Users and my company officers don't want to change operational circumstances of endusers. Just want to change install procedure currently by manual manpower visiting physical sites of users.
5)Developper Environment:Visual Studio 2010.
6)We don't afford to buy Install Shield, or other non-free software.
I assume a concept that can be fulfilled by custom actions of WiX. But if such server environment should not be contained to a distributable installer which faces against the hostile circumstances of user servers ( install might fail for unknown reasons), I don't need uninstall function to my installer. But if WiX designers don't expect such installer, I might be in wrong path...
Any ideas?
I'm a web developer thinking of moving work on our largest client's site to a Git workflow, but I am new to Git and am not sure how to integrate it with our client's .NET servers and IT folks.
The current workflow is: a co-worker and I work cooperatively on local versions of the site files, which we then push via FTP to the client's development server (accessible via VPN). Once the changes on their dev are approved, we have to catalog every changed file and email that list to our client's IT team. One of their team then manually pushes the changed files from dev to their production server. We are not allowed any access to the production server, as there are enterprise apps on it as well as the public-facing web directory.
A bit more awkwardness comes from the fact that the client's IT guys are all .NET developers and we are a Mac shop. Fortunately, the site files are 99% HTML/CSS .aspx files, so they are easy for us to work with. Occasionally, the IT guys post an .ascx form control we have to incorporate, but for the most part changes travel from us to them.
As the site has grown, the labor of cataloging changed files has become a bottleneck and a point of potential failure. I want to automate deployment and provide revision tracking and rollbacks. From our side of the router Git looks like the way to go.
But what do I propose for the client side of the workflow? My understanding is Git is not native to .NET or IIS. I doubt I will be able to persuade our client's IT guys to install and use a new toolset. Their main job is enterprise app development, and I get the feeling they don't exactly live for the thrill of pushing our web updates live.
I am not sure if i understand you right. But git with .NET is pretty much the same as in other technologies.
Here is a git extension to use with Visual Studio:
http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
Github is full of .NET projects.
I can't give you a advice to how to propose it. But git is definitly not a problem to use in VS or generally in .NET. They just have to switch.
You can also integrate git in your Team Foundation Server.
http://www.microsoft.com/en-us/download/details.aspx?id=30474
Git-TF is a set of cross-platform, command line tools that facilitate sharing of changes between TFS and Git. These tools allow a developer to use a local Git repository, and configure it to share changes with a TFS server. Using the tools, changes made in TFS can be pulled into a local Git repository, and changes made in the Git repository can be checked in to TFS. These tools can be used by individuals or teams collaborating using Git.
This way you could use both. TFS and Git for the same project. I think this could be a solution.
I am stuck with a problem that I could use some feedback on to solve it in the best possible way.
The issue revolves around source control -> automated builds -> deployment. Basically ALM (Application Lifecycle Management).
We have a product – an ASP.NET Web application with a MS SQL database. This product is running on hundreds of websites with associated databases across multiple virtual machines in our production environment. At the moment the web applications and database are running on servers with IIS 7 and SQL Database Server 2008 R2. The product itself is source controlled in Team Foundation 2012.
For years the release of new versions of the product has been once or twice a year for years. Now we are going to focus on releasing more frequently and hence we need a strategy for the ALM for the product.
The deployment strategy now:
In the development period between the releases, the SQL update scripts has been created manually – each time a database change was made a script was updated. When the application is ready to be deployed it gets compiled on a developer machine. The database with all the changes used would be backed up into a .BAK file. The web application, the .BAK file and the update SQL script would be packaged (.zip) and uploaded to the production environment ready for deployment.
Update existing running products:
Copy/paste the web application in the target website physical folder.
Update the web.config file – connectionstring and application
variables. Run the update script via SQL Management Studio
This would be done for each and every customer – hundreds of times.
This is a very tedious and error prone task and I don’t like it at all!
What I would like to do instead is;
Source control the database as a Database Project in Team Foundation
Automatically build the web application with Team Foundation 2012
Build Server.
Deploy the output from the Build Server to the multiple websites of
the production environment along with automatically generated SQL
update scripts run against the SQL Server.
I have been googling my ass off - only finding bits and pieces regarding builds, deployment, automatic SQL update script etc.
What I think is partly the right direction is to source control the database and use the TFS Build Server. I am very confused on how to do the deployment itself in an easy and controlled way using the output from the TFS Build server.
Ideally I would want to the TFS Build server to create a package with the latest version of the Web application, the latest version of the database, post deployment script including an auto generated SQL Update script from the previous build to the current build. This could be contained in e.g. a nuget package. Then I would want to be able to create an additional web application which should manage the deployment – target, version, iis website, sql server, web.config connectionstrings etc.
Does anyone have any advice on how to achieve this? How do you do this?
You can use a release management tool to do this, no need to create an additional web application.
One such example is Deployment Manager, from Red Gate. (Disclaimer: I work there.) It has built-in deployment actions for ASP.NET apps and SQL Server databases. The command line tool RgPublish.exe can be used to create a package for the web app as you describe from TFS Build. The same can be done for the database using the sqlCI.exe command line and associated NANT/MSBuild scripts.
The same packages can then be deployed to each of your servers. You may run into scalability issues with 100s of websites though.
The database deployment works by generating the upgrade script automatically, though you can change the behaviour to put the upgrade script in the package, when the package is first built. These are called "dynamic" and "static" upgrade methods respectively.
I don't know if this is possible, but I am trying to open a Visual Studio 2010 solution that is on a remote server from in Visual Studio. The project I am on is using Kentico CMS and we would like to be able to sync changes made to the hosted site (on the server) using TFS and Visual Studio as well as changes made via the Kentico CMS Desk portal. I haven't found anything on the Visual Studio or Kentico dev site or in the documentation. Whether or not this is possible, or if there is a better way of achieving this goal, I would appreciate any insight you could give.
I believe this system would help you accomplish syncing your development environment to a remote server.
http://www.kentico.com/Product/All-Features/Other-Modules/Staging-and-synchronization
You can check out what gets synced on this page:
http://devnet.kentico.com/docs/devguide/index.html
The content staging is good for synchronizing changes made via the user interface.
For synchronizing changes in the file system (e.g. changes in the code files in Visual studio), you can use some third party tools to keep the folders up to date - i.e. Drop box or Google drive (but there are also other tools and utilities).
After talking with a couple developers who were a bit more familiar with Kentico, we eventually found a good solution to our problem. It's not perfect, but it will work for our purposes.
We had the Kentico administrator generate a new license code for Kentico for 'localhost'.
In Visual Studio, we pulled down one of the default Kentico projects from the server.
On the project properties, we set Use Dynamic Ports to false and chose a number to set the ports to.
Once the project was built and running, we could navigate to 'localhost:1501/[ProjectName]/[PageName (CMSDesk, Landing.aspx, etc.)]' to access the CMS Desk portal.
In the CMS Site Manager, navigate to Sites > (click the Edit button for the site) > Domain Aliases > New Domain Alias and set a new domain alias (the website you want to use when viewing the site (for us it was dev.[projectname].com). This allows other developers to log onto and use the pages via the domain alias when the project is on the server. Changes made on the localhost copy must be pushed to the server before they are visible.
Using the local copy, we could work with the web parts and sync changes to TFS. We still have to manually copy the project from our local machine to the server in order to deploy, but we are hoping to set up a build machine that will push the TFS build to the server on a regular basis, which shouldn't be especially difficult.
If we find any better way to achieve this goal, or find any potential problems, I will be sure to update.