1

What I'm trying to do is to make test deployment easier. We're developing many features of a webpage at the same time, and it's come to the point where it takes a lot of time to get each version of these feature branches out to the test server so the customer who has the final say can test, give feedback/final OK on the changes made.

So I'm looking for a way to automate this and let the customer choose the git commit/branch from some kind of menu and then be taken to the correct version of the webpage. This way I don't have to update the test server, then let the customer know so they can test, then wait for feedback. It probably has to be a part of some kind of continuous build/testing integration? So the commit is built and can actually be run.

Any pointers to where I should start, what to read, software to check out would be highly appreciated.

Improve this question
2
  • 2
    This is a huge, huge, massive question and I have a feeling the answer is, essentially, it doesn't exist. Depending on your stack, I would recommend starting with Docker and a continuous build strategy that will build docker images. This will allow the user to load up the docker image and then use that image. I believe docker requires a unix based system, but I am not certain on that.
    – Paul Muir
    Commented May 18, 2016 at 14:37
  • Yes, that's what I thought as well. Requiring a Unix based system isn't a negative thing. I've messed around quit a bit with ASP.NET Core and have some projects already running under Linux.
    – Rune Antonsen
    Commented May 19, 2016 at 19:05

3 Answers 3

Reset to default
1

I would suggest that you do not use git feature branches for this and instead build this functionality into the application itself.

For controlling deployment you should be using tools such as capistrano and docker and processes such as blue-green deploy.

Your answer doesn't indicate what, if any tools or processes you are following so it's hard to advise without that.

Improve this answer
1

There is a major issue with having a lot of branches (and features) waiting for approval by clients. Mainly if clients do not test immediately and accept the work, the branches will not be merged into the main branch. This is a problem because other features will want to depend on this work and merging branches will become a real drama when your branches diverse for too long. Overall this sounds like a failing strategy.

I would try to keep just one test branch in which all features are merged continuously. Now to let clients test their requested feature I would suggest to try feature toggles. For each users you enable a feature with a toggle. Now the client can test the feature and when accepted you enable the feature for all users and you prepare it for deployment. This by either removing the feature toggle totally or by just enabling it for some users.

Do keep in mind that feature toggles are essential technical debt. You need to remove them as soon as possible or make them part of a right-system if you want do not want to enable this feature for 100% of the users.

Now having only one branch with all the finished work simplifies everything a lot, certainly when you have a lot of features that need accepting. Experience learns clients do not make time to accept work, maybe you can skip the test phase all together and just push changes into production by using feature toggles and remove them after you confirm the client is happy. My personal goal is deliver continuously, each commit should go into production to get the fastest feedback as you can. Unless you build life or dead applications, maybe testing in production is not such a good idea then.

Do think about what is the simplest thing possible and keeping the flow optimised so that developers can keep building on their previous work even if it is not yet accepted. Try to keep the number of open feature branches as low as possible at all times, since this will make the life of developers so much easier.

Improve this answer
0

To avoid running many different versions of the website, one for every commit/branch, you may need to use a lot of symlinks.

We do use something similar (with Subversion). You can checkout a branch, and script changes symlinks and restarts the relevant servers, so it "just works" and change takes few seconds (not counting checkout time). Of course some code changes require database changes, so then the magic breaks... :-(

Change of current branch of code is done by a script, not from web GUI - but that would possible too I guess.

But I do not think having such separate code instance would be feasible for every feature. It would be just way too many of them.

Improve this answer
2
  • This made me think of that I kinda have a checkout system already.. As I wrote in the comment on the question. I've set up a git hook to handle one project so when I push to the testing remote, the post-receive hook script fires, and it checks out the code, copies some files, runs some commands to restore and builds the project, and then it restarts the kestrel server.
    – Rune Antonsen
    Commented May 19, 2016 at 19:06
  • Maybe I could use this to let the commit to be checked out be chosen from a site then just load the website in an iframe within this choosing commit webpage some how. But then I would have to port the older projects over to ASP.NET Core which would be more time consuming then the current state, and it's still in RC :/ But this might be solution for the newer projects.
    – Rune Antonsen
    Commented May 19, 2016 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.