Timeline for Getting a single revision from Git
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 10, 2017 at 10:13 | comment | added | Tensibai | @RubyTuesdayDONO I've been unclear sorry, we have 2 apps like this, we deploy branches per environment, chef run every 30 mins on the machines and a simple merge into a branch allow a deploy within 30 mins. Preventing access to unit tests/non relevant files is done by the webserver configuration. I agree this is a simplistic case, and adding a level of overhead with a build/package/store wouldn't bring really much for those simple cases. That doesn't mean promoting it for everything, but I think it shouldn't be frowned upon on all cases neither. | |
| Mar 8, 2017 at 8:03 | comment | added | Rsf | Actually there is a reason to why we son't use achieved artifacts. Our product is part of a bigger build system, where each build might use a different revision of the product. That means we need to keep (or generate on the fly) an archive for each Git revision. Git archive solves most of that, with the exception of having unnecessary files. | |
| Mar 7, 2017 at 20:22 | comment | added | RubyTuesdayDONO | you don't mind if users see unit tests & other meta/planning docs? and you don't mind resolving merge failures when deploying? and you always want everything in the repo included in the delivered product, accepting unforeseen interactions w/ experimental features? yes, for simplistic/hobbyist cases, it's adequate to deploy your source repo -- but we shouldn't promote it as best practice. by the time you're trying to optimize away little things like storage overhead of the git object database (which is pretty good at deduplication), you might want to look at more explicit release methodologies. | |
| Mar 7, 2017 at 20:10 | comment | added | Tensibai | @RubyTuesdayDONO using git to deploy is perfectly fitting the goal in some situation, static angular js front ends are a good example of app absolutely ok to deploy with a git pull in my experience | |
| Mar 7, 2017 at 19:44 | history | edited | Pierre.Vriens♦ | CC BY-SA 3.0 |
integrate part of another comment (which at least to me further clarifies this answer)
|
| Mar 7, 2017 at 19:41 | comment | added | RubyTuesdayDONO | just saw your edit to put my comment in the answer, yes, thank you for that :) | |
| Mar 7, 2017 at 19:40 | comment | added | RubyTuesdayDONO | i don't purport that this is a complete or model answer, but i didn't see anyone else addressing the elephant in the room: if you use git to "deploy" your project, you're "gonna have a bad time" ;) | |
| Mar 7, 2017 at 19:38 | comment | added | Pierre.Vriens♦ | Please check my edit of your answer (just integrated your interesting comment). Feel free to improve/rework of course, or just rollback if you don't like my edit at all. BTW: your comment (= note I added) made me think like "really, that simple? Again a sample of how we Get Things Done in zOS ... with z for zero downtime ...". I think it's time to start to question way more questions/answers via similar comments ... Don't challenge me too much ... | |
| Mar 7, 2017 at 19:34 | comment | added | Tensibai | Then I don't see what this brings more than the accepted answer, if it's to point toward fit archive... it's just redundant, you should edit to extend on this way iMHo | |
| Mar 7, 2017 at 19:33 | history | edited | Pierre.Vriens♦ | CC BY-SA 3.0 |
Integrate comments from OPer
|
| Mar 7, 2017 at 19:32 | comment | added | Tensibai | @Pierre.Vriens yes, you're missing what's is suggested as tarring an archive, I.e building an artifact with just the necessary files in it to be deployed. That said I agree that's not a quality answer and this point should be extended. We are in private beta and answers should née explicit | |
| Mar 7, 2017 at 19:30 | comment | added | RubyTuesdayDONO | it's okay to question (or even challenge!) an answer -- that's what makes Stack Exchange great :) for repositories of scripted languages that don't really have a "build" step, a trivial way to release an artifact would be to package them in an archive, such as tar or rpm. then, to "deploy", you untar the archive or install the rpm. this removes the need for git tooling in your deploy chain (not all prod servers will have those dev tools) | |
| Mar 7, 2017 at 19:04 | review | First posts | |||
| Mar 7, 2017 at 19:17 | |||||
| Mar 7, 2017 at 18:56 | history | answered | RubyTuesdayDONO | CC BY-SA 3.0 |