So I have a server where I keep development files used for my game server. With multiple developers, I was wondering if there is a way to have the repository located on that server automatically pull new files as my developers push their commits to the online master? I have looked into ngrok but am unable to figure out how to implement this as this is not a web server and the files are not located on the root drive of the computer. Hope someone can give me a good step by step or point me in the right direction of a tutorial!
If you are on linux you can use crontab, on windows you can use Windows Task Scheduler
Related
I'm a newbie to version control systems, so please pardon my naiveté.
I want the repository to be on a networked path within our local area network (LAN) so that only local PC's can access it. The files that are edited should be on a server which is accessible via the internet.
Here is a diagram of what I mean:
The Internet server is an ordinary web server, but it offers WebDAV. Is there a version control system with which I can implement this setup?
Sure. What you are trying to achieve is called continuous deployment. You can set up a git server locally and then deploy the build artifacts to the WebDAV server (and/or another server) online.
⚠️ Note
I strongly recommend not running your version control software (VCS) locally, but rather, having a private repo on GitHub, GitLab, AWS CodeCommit, Azure DevOps, or BitBucket that you clone locally for work.
If you're committed (no pun intended) to local VCS, then you can use the set up below.
Continuous Deployment
You can create a local scheduled script to check for critical events (like approved merges on the main branch) of a target local repo. The script will then build the entire project and copy the build artifacts to the WebDAV.
There are almost an infinite number of ways to achieving this, so I will just link to some high level guides:
What is a Deployment pipeline?
Continuous Integration, Delivery, and Deployment
Windows Scheduled Tasks Azure DevOps Extension
scheduling continuous integration pipelines
The script can be as simple as copying files from the repo to the WebDAV; or, as complex as integrating, testing, building, and pushing build artifacts. The specifics (which scripting language[s] and how to schedule) depend on your OS more than anything. Here are instructions for Windows: https://blog.netwrix.com/2018/07/03/how-to-automate-powershell-scripts-with-task-scheduler/
git Server on LAN
Before you can deploy, you need a repo. The following are steps (using Windows 10) to get your local git server going. If you are using a Linux flavour, please adjust the instructions accordingly.
Create a folder where you want to create the Git Server.
Move into that folder, right click and select
Git Bash Here
option. This will open a bash command window in the current
folder.
Run the command
git init anyname.git --bare
to initialize Git bare repo without the working directory.
That’s it. You have successfully set up your Git server.
Connecting to Local Git Server
On your Git server, Go to control panel → Network And Sharing
Center > Change advanced sharing settings. Select
Turn on network discovery option
and
Turn on file and printer sharing
option.
On your Git server, Go to control panel → Windows Defender
Firewall → Advanced Settings → Inbound Rules. Enable
File and Printer Sharing (NB-Name-In) on private,public
profile and
File and Printer Sharing (SMB-In)
on private, public profile
as shown below.
Go to the folder you have created Git Server, right click and select
properties. Under
sharing
tab, click
Share
and add
Everyone. Set the
permission level
as
Read/Write.
Once the permissions are set, you will find a share path.
Go to second Windows PC and open Git terminal and type
*git clone //GitServerName/PathToGitServerFolder.git *
command.
You can create new files and folders as if you do on a normal Git
account.
That’s it. You have successfully created your own Git Server
and published on the network.
The simplest way that I can think of, though it take a little getting used to is GIT.
You can do this with local repo C:/some/path/to/repo and the upstream as E:/webdav/location or //link/to/webdav, and just push to upstream to update on the server.
We are looking to set-up source control on a Windows remote development server. The source code should never leave this server. Can we use Github Desktop in this scenario to simply manage a local repository and never send the code off the server? If not, is there some other simple way to achieve this?
First, I'm a TFS novice. I have a situation where I'm running TFS, and want to interact with a domain outside our environment. The destination server environment does not want to establish any trusts due to security\confidentiality reasons. I was thinking of using a BuildServer or second TFS server in the remote environment to accept the files from the (local) source TFS.
For anyone else looking to do this, I found out there is a way to do it, however it's certainly not a plug-n-play.
The steps would be:
Using the TFS API, write a solution to watch for check-in actions. When one is found, wait until the action is completed then copy all items to a temporary location.
This temporary is actually a secure FTP location that would send the files to the client site.
Once on the destination client, a folder watcher scans for changes.
When the FTP process is complete, a TFS API solution application call is made to check in the files to the destination TFS.
I've been testing TFS in the cloud, and have it all set up with a test project. Not using Git currently. My question is related to publishing to our remote server. I have a drive mapped and connect over VPN, and publishing via file system works. It appears that publishing occurs from my local solution, and not the solution in the central repository. This allows files that are checked out to be published to production. I had thought publishing would occur from the central repository, and only publish the files that are checked in.
Is the publishing process supposed to move the files from the central repo? Or, am I doing something wrong?
If not, are there controls in TFS to only publish approved/tested production files, and only files that are checked in? For example, prevent publishing and notify developer if files are checked out.
It's been a long time since I've used SCM, so bear with me. Thanks for your patience.
I think you need to investigate the build service built into TFS as this will let you generate builds using only the checked in source. A guide to doing this using the TFS cloud can be found here.
I'm learning FluentMigrator. The thing that I like about FM is that it supports the idea of Forward and Back for migrations (aka Up/Down). I'm finding that it's not ideal about this; there are some holes. Still, it's good.
This leads me to wonder if there are any deployment tools (nant, msbuild or other) that support this idea of rolling forward and back. The scenario that I'm using it in is the deployment of a web app with a related database.
Ideally I'd like to set up my deployment so that, should any part of it fail, it will revert to the previous known working configuration. With FM, this is pretty easy to do (but there are rough spots), so that covers the db. How about the files that make up the web app? Do any deploy tools have support for this?
Deploying to a Windows Server. Assume that I can't make any changes to the server.
I don't know of any Microsoft-centric, automated provisioning/deployment tools like Capistrano. Here are some tools I've heard of, but never used:
MSDeploy, for deploying web application.
Microsoft Deployment Services, for managing operating system configuration
Microsoft's System Center Configuration Manager
BladeLogic
HP's Operations Center
Up until about three months ago, we did our deployment/provisioning using custom MSBuild scripts. After a server is provisioned, deploys happen automatically using Robocopy to copy files to a share on the application server, updating changed application binaries and markup files. We've never had a need to rollback any of our deployments, but since our scripts are custom, we could write the logic if we needed to.
MSBuild is a terrible deployment/provisioning language. For the past three months, we've been writing all new scripts in, and porting existing ones to, PowerShell. It is wonderful. With version 2, there is support for running commands on remote servers, like SSH. We haven't used that functionality yet, but I'm looking forward to pushing setup scripts to remote server to provision and deploy at the same time.
We have been using Git to do our deploys for the last 6 months.
Here is the whole process:
CI server build the project
CI server checks it in to a local git repository
CI server pushes the changes to the centralised git repository
User creates an empty repository on the live server
User adds the central git repository to the remotes
User pulls the latest version over https (no need to open any ports)
It is a lot to setup in the beginning but once setup it works great. Deploys take seconds as only changed files get copied.
Another great thing about this method is that git keeps history of changes so rolling back is pretty simple. You can also roll back a few revisions and it's done straight on the live server. If something goes wrong reverting is super fast.
Also you can save some time if you use a hosted git service (github) for your central repository.
This is a very brief description but I can give you more info if you want.
Of course! My favorite is Capistrano. This was originally built for Ruby but I've found that it works just as well for other languages.
https://github.com/capistrano/capistrano