I am working on setting up a development/deploy cycle for one of our latest projects. Here is what I am trying to do,
Commit the latest code to local "mercurial" clone.
Push it to central repo hosted at "bitbucket"
Open some web based management console (this is the part I need help with) on my server, which is already configured to use the bitbucket repo automatically fetches the latest commits and shows a list.
Choose one of the revisions and perform an update which will effectively update the website.
If there are some issues with the latest revision, go back to previous version using the same web console.
I am using "SourceTree" for step1 and step2 and I want to keep the whole cycle GUI based. Can anyone suggest any tool which I can use for the server side management (step 3,4,5) ?
This is more simple than you'd think:
Clone the website on your server using bitbucket as the source
Write a small web app which calls hg pull -u in the root folder of your website. Mercurial remembers where to pull from, so you won't need anything here.
The second feature can be implemented using hg id -i (see this answer) to get the current revision. Write that to file.
Now you need a web page which lists all the revisions in that file and runs hg up -r <revision> when you click on one of them.
But maybe a better approach would be to push directly to the web server using hg push from your local repo (see here). You can then use a hook to update the files and save the last revision to a file.
Now you'll only need a web service to revert to a former revision.
Team City is a web app which can do that for you.
It is a continuous integration server but can be configured to only publish when you use the application.
There are many continuous integration servers and I imagine that most/all can do what you want so search around if that one doesn't quite fit your needs.
Related
I am new to developing Google Sheets scripts. I have code forked from krlaframboise/SmartThings and would like to make some additions and commit those to my Github fork. I can obviously edit in the sheet script editor and paste those back to my git repository but that doesn't seem ideal. What are some good patterns for developing Google Sheets scripts and tracking in Github?
Best solution I've found is GAS Github Assistant.
It's a Chrome Extension that integrates with the Apps Script IDE and allows you to pull/push code from/to your repos at the click of a button.
It not only supports Github but Bitbucket as well.
UPDATE 1/30/2018
Apps Script now has a command-line interface called clasp that offers similar functionality.
If your changes are data changes that should correspond to code changes then you should follow the pattern that good database administrators have use for years.
Make the updates with code as an upgrade script checked into source. You should also make a downgrade script that undoes the changes and check it in.
If making the changes programmatically is a headache, then make the two files simply contain instructions on how to make the data changes. Include an upgrade and downgrade instruction file with each major release.
I wrote a tool to pull and push google-apps-script code from/to from Google Drive. It avoids having to copy paste code.
Your use case would be as simple as this:
$ gas pull && git commit -m 'Some changes I made'
Ive been programming for a little while now and have built a little application which is now hosted on a dedicated server.
Now i have been rolling out different versions of my app with no real understanding on how to manage the process properly.
Is this the proper way to manage a build of an application when using a product like git hub ?
Upload my entire application onto github.
Each time i work on it, download it and install it on my dev server.
When im done working on it and it appears to be ok, do i then upload the changed files with the current project i am working on or am i meant to update the entire lot or am i mean to create a new version of the project?
once all my changes are updated, is there anyway of pushing these to a production machine from git hub or generating a listing of the newly changed files so i can update production machine easily with a checklist of some kind ?
My application has about 900 files associated with it and is stored in various folder structures and is a server based app (coldfusion to be precise) and as i work alone majority of the time, im struggling to understand how to manage the development of an app...
I also have no idea on using the command line and my desktop machine is a mac, with a VM running all my required server apps (windows server 2012, MSSQL 2012 etc)
I really want to make sure i can keep my dev process in order, but ive struggled with how to understand how to manage a server side apps development when im using a mac my dev machine is a windows machine i feel like im stuck in the middle.
You make it sound more complicated than it is.
Upload my entire application onto github.
Well, this is actually 2 steps: First, create a local git repo (git init), then push your repo up to github.
Each time i work on it, download it and install it on my dev server.
Well, you only need to "download" it once to a new dev box. After that, just git pull (or git fetch depending on workflow), which ensures any changes on the server are pulled down. Just the deltas are sent.
Git is a distributed version control system. That means every git repo has the full history of the entire project. So only deltas need to be sent. (This really helps when multiple people are hacking on a project).
When im done working on it and it appears to be ok, do i then upload the changed files with the current project i am working on or am i meant to update the entire lot or am i mean to create a new version of the project?
Hmm, you are using fuzzy terminology here. When you are done editing, you first commit locally (git add ...; git commit), then you push the changes to github (git push). Only the deltas are sent. Every commit is "a new version" if you squint.
Later on, if you want to think in terms of "software releases" (i.e. releasing "version 1.1" after many commits), you can use git tags. But don't worry about that right away.
once all my changes are updated, is there anyway of pushing these to a production machine from git hub or
generating a listing of the newly changed files so i can update production machine easily with a checklist of some kind ?
Never manually mess around with files manually on your server. The server should ONLY be allowed to run a valid, checked-out version of your software. If your production server is running random bits of code, nobody will be able to reproduce problems because they aren't in the version control system.
The super-simple way to deploy is to do a git clone on your server (one time), then git pull to update the code. So you push a change to github, then pull the change from your server.
More advanced, you will want something like capistrano that will manage the checkouts for you, and break up "checking out" from "deploying" to allow for easier rollback, etc. There may be windows-specific ways of doing that too. (Sorry, I'm a Linux guy.)
Is Clone the only way for me to get my own repository to a different machine?
I have published my repository from my home PC and am trying to edit it from another.
I'm using Github for Windows but cannot see how to get the published repository to a second machine in order to edit the code and republish the changes so I can later use on the original PC.
The general approach for Distributed Version Control Systems is to:
Clone the repository (from the server)
Update your code (local, in your working directory)
Commit the code (local, in your working directory)
Push the commits (to the server)
Pull the new commits (from the server) to another development PC.
Typical development cycles iterate between steps 2 and 3. And sometimes 4 (to store your changes off-site) and 5 (to grab changed made by others).
As I suppose that 'Github for Windows' uses git(hub), it is also a DVCS and works also with these steps.
The proper way to do this is to clone the repository onto your second machine, straight from the source (Github). Sharing one clone between multiple machines is not recommended except in a few circumstances.
Resolved.
I had to delete the local repository. Github then prompted me with an error and the option to "Clone again", this clone again worked.
Thanks.
I've recently been looking at using Git to eventually replace the CVS repository we have at work. However after watching Linus Torvalds' video on YouTube about Git it seems that every tutorial I find suggests using Git in the same way CVS is used except that you have a local repository which I agree is very useful for speed and distribution.
However the tutorials suggest that what you do is each clone the repository you want to develop on from a remote location and that when changes are made you commit locally building up a history to help with merge control. When you are ready to commit your changes you then push them to the remote location, but first you fetch changes to check for merge conflicts (just like CVS).
However in Linus' video he describe the functionality of Git as a group of developers working on some code pushing and fetching from each other as needed, not using a remote location i.e. a centralized location. He also describes people pushing their changes out to verifiers who fetch and push code also. So you can see it's possible to create scalable structure within a company also.
My question is can anybody point me in the direction of some tutorials that actually explain how to do this distributed development of code using Git so that developers push and fetch code from each other with out committing to the remote repository and if possible it would be very nice to have this tutorials Eclipsed based.
Thanks in advance,
Alexei Blue.
I don't know any specific tutorial about this. In general, for connecting to a repository, you have to be running a git server that listens (and authenticates) to git requests.
To have a specific repository for each developer is possible - but each repository needs that server component. It is possible to store multiple repositories on the same computer, that allows reducing the number of servers required.
However, for other reasons it is beneficial to have some kind of central structure (e.g. a repository for stuff to be released; or a repository for stuff not verified yet). This structure is not required to be a single central repository, but multiple ones with well-defined workflows regarding the data move between repositories (e.g. if code from the verification repository is validated, it should be pushed to the release repository).
In other words, you should be ready to create Git servers (e.g. see http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux for details; but there are other tutorials for this as well), and define workflows for your own company to use it.
Additionally, I recommend looking at AlBlue's blog series called Git Tip of the Week.
Finally, to ease the introduction I suggest to first introduce Git as a direct replacement for CVS, and then present the other changes one by one.
Take a look at alblue's blog entry on Gerrit
This shows a workflow different from the classic centralized server such as CVS or SVN. Superficially it looks similar as you pull the source from a central Git server, but you push your commits to the Gerrit server that can compile and test the code to make sure it works before eventually pushing the changes to the central Git server.
Now instead of pushing the changes to Gerrit, you could have pushed the code to your pair programming buddy and he could have manually reviewed and tested the code.
Or maybe you're going on holiday and a colleague will finish the task you've started. No problem, just push your changes to their Git repo.
Git doesn't treat any of these other Git instances any different from each other. From Git's perspective, none of them are special.
I am using MACOS for Developing the iPhone Application.
I have made the repository in to some Public Site that gives Functionality to build the Repository in their server and after that we can use the project to work simultaneously. But it uses internet connection that's why it becomes to slow to update and modification.
I have multiple Computers and I want to Use One PC as a Server and want to Create the Repository there and after from another multiple Computer, I want to use the Same Project to be done simultaneously.
How can i done that settings or that kind repository ?
Please help me regarding this.
I will suggest you to use mercurial rather than subversion. so any one can commit locally and once the server is up, just push the changes.
SVN is a centralised and
hg is a distributed control version system
The main difference b/w
Subversion uses one main directory to store the versionned version and can deploy (export) a specific revision at anytime.
whereas
Mercurial repository holds both the current public version and all the history. You do not have to deploy anything anywhere, just update your current repo with data from one of the revision.
and when you are using hg you do not really need to wait your server up, you can commit locally and push your changes once server up :)
To know more about look at HERE
If you are using osx, chances are svn is already installed on the computer you want to use as a host. You can configure svn to work with apache and use your local machine as the svn host. The following link has the details for setting it up:
http://mark-kirby.co.uk/2008/how-to-set-up-and-use-subversion-svn-on-os-x-leopard/