0

We have a repo in a strict development environment and private webserver residing in /var/www/dev/repo. We want any branches that are created to automatically be created and added to /var/www/branches/feature-coolfeature and auto-based on the master-branch (or the "base on branch"). This way we can very easily load, codewise, the new branch in to our /var/www/dev/repo and demo our new branch-features for clients and product owners.

Think of a "branch-switcher" in our platform that will switch between development branches. In addition, we want to be able to do commits to /var/www/branches/feature-coolfeature, both directly on the server in the given folder but also through Github Desktop for example.

We understand we may be very far out on this one and appreciate any pointers on where we can go with this flow, or even try a totally different one. So far we've managed to through Github webhooks create the folder structure and copy everything from the original repository, except it doesn't understand it's actually a branch (thinks it's the master-branch) and we're just seeing several signs that we're approaching this problem from a very, very bad angle. Both github-related but also permission-wise. We're developers trying to learn DevOps.

Would appreciate any and all advice.

Oscar Eriksen
  • 1
  • It's not such a bad approach. But at the point where you're switching branches, why not just have the github push hook trigger a fetch and pull to the repo in /var/www/dev/repo ? And have the branch switcher check out a particular branch? I don't really understand how having each branch in a different directory helps you. – erik258 Jan 06 '17 at 00:15
  • First, we want different clients to be able to test out different branches based on session or cookie-data. This is actually "working" with the current setup. Secondly, we want the branches to not be saved within the actual /var/www/dev/repo-folder but outside of it. Thirdly, and I'm ashamed to type this out, but we want to be able to do direct development to it through SFTP and, both through Github Desktop and on server do direct git commits to it. – Oscar Eriksen Jan 06 '17 at 00:21
  • the only thing I think is an exceedingly bad idea is that last part. You are going to lose changes and step on each other's toes, period, if you don't use a change management system. If your branches are automatically pulled to the server on commit, I really don't see the point of the sftp. Otherwise, I think it's a fine, though perhaps a bit novel, approach. – erik258 Jan 06 '17 at 16:24

1 Answers1

-2

Well, third wish is just piece of shit - you must to re-think about it, your current and future workflow in order do not cry in nearest future (I сan understand background of your needs, but you must to remember: "Each problem has at least one obvious, simple and WRONG solution")

  1. Any pure developer can't be (and never will be) proper DevOp. Just because DevOp'ing require another and wider mindset, not limited to "I can to code-code-code it"... you have stepped on the rake and cheerfully going to run on them
  2. Today you have to have in team at least (except devs):
    • good admin of used WWW-server (good because he have to know it under the good and used because different servers are... well... dfferent: it's not a problem for me to build dynamic vhosts in Apache, but I'll fail without prior RTFM in Boa, Tomcat, IIS, lighttpd, Nginx...)
    • advanced Git-user (git-hooks will be not so obvious in 'ready to Prod' state, ordinary git-boys aren't good in technical details, contrary to fanatical preaching)
    • good NetworkAdmin (if you'll select to have and use two remote systems - your host and GitHub, single point is just more easy and transparent way - see below)

GitHub, as 1) remote system 2) which you doesn't own and can't manage at 100% isn't reasonable smart choice: you'll always have limitations of remote hosted solution and additional level of complexity (remote communication GitHub - Dev environment) and additional point of failure. The are a lot of usable Git-centric solutions now (from just serving repos to full ALM-cycle), which can be deployed on local systems

PS: OK, you exhausted the limit of my free consulting, but can hire me for not-free (any size anytime)

Lazy Badger
  • 3,137
  • 15
  • 13