January 21st, 2017, 09:31 AM
Version Control Hosting
Ok so i am new to version control systems and im trying to get my head around bitbucket and git. So from my understanding bitbucket is a hosting service that hosts GIT/Mercurial version control systems. If i want to use a version control system when i build my next website, then can i set it up in either of these two ways?
(a) install and configure GIT on my own remote server and setup my IDE to connect to that repository - so effectively bitbucket is not in the loop at all;
(b) install and configure GIT on my own remote server, setup the repository on both bitbucket and my own remote server, push my changes to the bitbucket account and then have a webhook run on a certain command that pushes all outstanding changes to my own remote server when needed?
Is that how a deployment typically runs in the wild? Why use bitbucket at all if you can take it out of the loop? I'm guessing its used as a visual interface to show the list of changes etc?
January 21st, 2017, 11:06 AM
Git and Mercurial are decentralized: you can put as many copies wherever you want so long as you don't have any problems keeping them all in sync; one local copy (for yourself) and one remote copy (the authoritative version) is generally best. You actually don't have to keep them in sync, but not doing so will probably backfire on you in the future.
So yes, you could do (a) and disregard Bitbucket. But the point of services like that is to give you much more than Git alone has: an interface, support for users, authorization rules, repository forks, backups in case of failure, automated hooks...
(b) is also fine, and how "continuous integration" (automated testing and deployment) typically works.
In the wild it's the wild west. Using hosting services is increasingly common, and continuous integration is growing in use, but there is no "typical" setup.
If you're new to this then host your source in Bitbucket and do manual deployments for now. As you get comfortable you can start thinking about doing more. One step at a time.
Comments on this post
January 23rd, 2017, 05:07 PM
We host our own git repository using Atlassian Stash software (now called Bitbucket server). Our stash repo runs on our own server, not on bitbucket.org. We check in all our code to our stash instance and when we deploy, we pull a branch out from it to our production servers. We also use other atlassian products in our setup (JIRA for tracking bugs, Confluence for our wiki, Bamboo and jenkins for automated tests etc.) and stash integrates nicely with them
However, most of the time, I don't use the GUI interface.
The way it works is:
(a) Check out the 'develop' branch from the remote repo (stash) onto our individual developer boxes (i.e. git pull origin develop)
(b) Create a new branch locally from the 'develop' branch (usually named after a ticket on JIRA that describes the issue. So if the JIRA ticket is MYPROD ticket 1234, this branch would be called "MYPROD-1234" and we run "git checkout -b MYPROD-1234")
(c) Make the changes on the local branch and commit changes as needed (git commit). If it takes more than a few days, pushing changes to the remote repo under the new branch name is a good idea as well, so there is a remote copy as well (git push origin MYPROD-1234)
(d) When the feature is fully implemented, then the developer commits and makes one final push to the remote repo. Then, the developer then logs into the stash UI and creates a "pull request", requesting to merge the changes from MYPROD-1234 to the develop branch. This automatically sends emails out to the members of the MYPROD team saying that developer blah has made a change for ticket MYPROD-1234, please review.
(e) One or more people are required to code-review the change (the differences can be compared on the stash UI) and post comments/suggestions or approve the changes. The developer makes recommended changes if needed and repushes the changes to remote repo, until we are happy with the changes.
(g) When changes are approved, I log into the stash GUI and push the button to merge those changes into our 'develop' branch.
With this setup, I can have multiple people working on different issues simultaneously and only merge what I want into the 'develop' branch. This way, if one member of my team has implemented a new feature, while another member has only partial code, I can make sure that the partial code stays out of the develop branch until fully ready.
Periodically, I make a pull request to merge the develop branch into a 'qa' branch, which is then deployed to the QA machines, so that the qa guys can validate the upcoming release, while my dev. team works on newer features. Any bugs that the qa team finds are fixed by cutting a branch off the qa branch and then merging back to develop and qa branches. When qa is passed, I generate another pull request to merge qa into the 'master' branch and tag it.
Then, on my production machines, I configure them to pull the 'master' branch from the remote repo. This means the production machines are running code that has passed the qa process. Meanwhile my developers are making new changes off of the 'develop' branch, so no downtime is needed.
Then the cycle repeats....
Since all the atlassian products play well with each other, I can easily create a new git branch from JIRA directly if I like and have it linked to the wiki and what not, which is very cool.
Last edited by Scorpions4ever; January 23rd, 2017 at 05:38 PM.
Up the Irons
What Would Jimi Do? Smash amps. Burn guitar. Take the groupies home.
"Death Before Dishonour, my Friends!!" - Bruce D ickinson, Iron Maiden Aug 20, 2005 @ OzzFest
Down with Sharon Osbourne
"I wouldn't hire a butcher to fix my car. I also wouldn't hire a marketing firm to build my website." - Nilpo