Is Git really suitable for deployment? I thought that Git have full history of the past versions which moves a lot extra bytes when you are firing up a new instance. It may be interesting if one could use git's pull/push to have some distributed deployment system (still far from BT protocol based one, but interesting topic though).
In any case, I fail to see how this is any more useful than Capistrano. Just being able to push arbitrary tree-ish hashes to a specific environment isn't very special, as that can arguably already be done with Capistrano.
It is not _just_ about pushing though. It is also about the modularity and additional server provisioning that it adds. You define your environment through modules, and Git Pusshuten helps you set it up, at least enough to get up and running really quick. Of course, it isn't for everyone. Just like a VPS isn't for everyone, and just like Heroku isn't for everyone.
This also introduces perhaps a new workflow to many people, if you already work with Git. As you said, it isn't very special pushing any branch to any remote location. However, it has not yet been done by anyone else yet (from what I can see, I might be wrong).
For a lot of people, (again, not everyone), it is a joy to be able to spin up a VPS, being able to provision it with pre-configured settings and common dependencies with a few commands, and being able to have your application live in a matter of a few minutes without needing almost _any_ knowledge of Linux.
I'm in the process of finishing two side-projects and just started thinking about deployment. I wasn't sure what to use for deployment, as I just wanted to run two web-apps on a VPS. This is definitely what I'm going to use.
Of course it isn't for everyone and every project, but it's good (and simple) enough for me.
Every project has different requirements for deployment and I sure appreciate the option to chose from a variety of tools.
Frankly, trying to do anything even slightly off the beaten path with capistrano leads to madness in my experience. If this is simpler to extend past just deploying rails apps I can definitely see a place for it in my workflow.
The problem with capistrano is that it tries to abstract a bit too much of the underlying project and deployment environment away. minicap aims to fix that by providing a minimal, git-centric remote footprint. cap provides a great foundation, but makes a couple of mistakes in its recipes that are easily remedied with a minimalist approach like we've taken in minicap.
"git archive" is the closest to what you're looking for I think (although, that only creates a zip or tar archive, so you need to add an extra step -- by default it writes to stdout though so it's not too hard)
The little sysadmin in the back of my head says 'no', but I can see this sort of thing being very useful for small projects.
For companies with security and/or compliance needs, or paranoid people like me, it's more-or-less vital to keep development and production separated, and to firewall the hell out of what production can actually go out and get, as well as to tightly control who and what has access to the servers.
Most systems like this make the assumption that you've got full root-level access via SSH, which is often not the case. Likewise, I don't see anything for handling multiple servers (maybe I missed that?).
This is correct. If you rely on a lot of security then maybe you should be considering a different deployment method, or write a module that does exactly what you want to do. It is modular so there is the probability you could accomplish what you want.
Also, the project just released a few days ago, mainly to say it's there, if anyone wants to contribute or provide feedback that would be very much appreciated. It is still in a _very_ early stage, hence the version 0.0.x so it could really go in a lot of directions, mainly based on input from the community and guys like you. There is a lot of room for improvement.
That said, any piece of information, advice and feedback is most certainly welcome!
Are there dashes in Japanese? I suppose the interpunct character (・) best represents the idea.
The ー character is typically used with hiragana and katakana to elongate the previous character's tailing sound: リー for the name Lee (rii), メートル for meter (meetoru), as examples.
The ー character is not used after kanji because their sound cannot be elongated.
There are a few flavors of dashes in modern Japanese documents. Only one of the following three characters is a dash. ー―一 If you were aiming for a dash, you want the one in the middle, because the two to either side are very definitely not dashes.
The nobasu character (ー) ordinarily lengthens the vowel sound directly preceding it when you are reading katakana, the Japanese syllabary most commonly used for writing foreign words. 天 is kanji, and having ー after that is, well, if Japanese had a spec it would leave that behavior undefined.
[Edit: swap "proceeding" for "preceding." Engrish is hard.]
Others have already explained the elongation mark, but for those who are interested, there are so many foreign words that have been borrowed into Japanese that sometimes you get words that differ only in the usage of that elongation mark.
ビル: pronounced "biru" is a shortened word meaning building.
ビール: pronounced "biiru" means beer.
I really wonder if people just look at the title and see "Git deployment" and then assume it's exactly like all the other git deployment projects out there and then comment here. Or, if they actually _read_ the contents of the website and understand what it's all about.
If you read the website you will see that Git Pusshuten can do more than just do a simple "git push" like other solutions.
Git Deploy by Mislav makes the assumptions you work with: Passenger, Ruby on Rails, etc. Git Pusshuten doesn't make such assumptions. It allows you to deploy an application, regardless of whether you're deploying a Ruby, Python, PHP, etc application, to whatever web server by defining _your_ environment through modules.
Additionally, it allows you to provision and pre-configure your environment so you can be up and running with minimal effort and sysadmin knowledge. Other solutions will make you manually set up your environment by SSH'ing into the server to configure everything. Now, I am definitely not saying that that is a bad thing. I'm just saying that Git Pusshuten's _goal_ is entirely different from that of Git Deploy.
So what you're pointing out now would only work for people using Phusion Passenger and a Rack application. That's a limitation that Git Pusshuten is trying to avoid.
Pro-tip: list the differences between your project and other similar projects on the project web page. Compare and contrast. State clearly and specifically how it's unique.
I could do a comparison. However, I prefer to just talk about what this does, rather than what other projects do or don't do. I have a lot of content already as it.
If you read the main page, you will (hopefully) in most cases come to understand what this tool does. You will remember it, then look at other projects that also handle deployment and see if they satisfy your needs.
You make a list of the tools you might use and try them out. Now you're doing the comparison and "experiencing" what works best for you yourself, rather than listening to my (perhaps in 3 months) outdated information which might be inaccurate.
Now, for convenience I agree that I could make a list to summarize what this is all about but I'm not sure if there's any need for it. The 3 main aspects are covered: "Core", "Hooks", "Modules" and a video demonstrating something very basic.
Regardless, as I already said, any input is welcome and I'll certainly take it into consideration. Thanks!
28 comments
[ 3.1 ms ] story [ 67.8 ms ] threadIn any case, I fail to see how this is any more useful than Capistrano. Just being able to push arbitrary tree-ish hashes to a specific environment isn't very special, as that can arguably already be done with Capistrano.
This also introduces perhaps a new workflow to many people, if you already work with Git. As you said, it isn't very special pushing any branch to any remote location. However, it has not yet been done by anyone else yet (from what I can see, I might be wrong).
For a lot of people, (again, not everyone), it is a joy to be able to spin up a VPS, being able to provision it with pre-configured settings and common dependencies with a few commands, and being able to have your application live in a matter of a few minutes without needing almost _any_ knowledge of Linux.
Of course it isn't for everyone and every project, but it's good (and simple) enough for me. Every project has different requirements for deployment and I sure appreciate the option to chose from a variety of tools.
The problem with capistrano is that it tries to abstract a bit too much of the underlying project and deployment environment away. minicap aims to fix that by providing a minimal, git-centric remote footprint. cap provides a great foundation, but makes a couple of mistakes in its recipes that are easily remedied with a minimalist approach like we've taken in minicap.
For companies with security and/or compliance needs, or paranoid people like me, it's more-or-less vital to keep development and production separated, and to firewall the hell out of what production can actually go out and get, as well as to tightly control who and what has access to the servers.
Most systems like this make the assumption that you've got full root-level access via SSH, which is often not the case. Likewise, I don't see anything for handling multiple servers (maybe I missed that?).
Also, the project just released a few days ago, mainly to say it's there, if anyone wants to contribute or provide feedback that would be very much appreciated. It is still in a _very_ early stage, hence the version 0.0.x so it could really go in a lot of directions, mainly based on input from the community and guys like you. There is a lot of room for improvement.
That said, any piece of information, advice and feedback is most certainly welcome!
The ー character is typically used with hiragana and katakana to elongate the previous character's tailing sound: リー for the name Lee (rii), メートル for meter (meetoru), as examples.
The ー character is not used after kanji because their sound cannot be elongated.
"The nobasu character (ー) ordinarily lengthens the vowel sound directly proceeding it"
But did not know that it "had" to be directly followed by katakana. :)
[Edit: swap "proceeding" for "preceding." Engrish is hard.]
ビル: pronounced "biru" is a shortened word meaning building. ビール: pronounced "biiru" means beer.
If you read the website you will see that Git Pusshuten can do more than just do a simple "git push" like other solutions.
Git Deploy by Mislav makes the assumptions you work with: Passenger, Ruby on Rails, etc. Git Pusshuten doesn't make such assumptions. It allows you to deploy an application, regardless of whether you're deploying a Ruby, Python, PHP, etc application, to whatever web server by defining _your_ environment through modules.
Additionally, it allows you to provision and pre-configure your environment so you can be up and running with minimal effort and sysadmin knowledge. Other solutions will make you manually set up your environment by SSH'ing into the server to configure everything. Now, I am definitely not saying that that is a bad thing. I'm just saying that Git Pusshuten's _goal_ is entirely different from that of Git Deploy.
So what you're pointing out now would only work for people using Phusion Passenger and a Rack application. That's a limitation that Git Pusshuten is trying to avoid.
If you read the main page, you will (hopefully) in most cases come to understand what this tool does. You will remember it, then look at other projects that also handle deployment and see if they satisfy your needs. You make a list of the tools you might use and try them out. Now you're doing the comparison and "experiencing" what works best for you yourself, rather than listening to my (perhaps in 3 months) outdated information which might be inaccurate.
Now, for convenience I agree that I could make a list to summarize what this is all about but I'm not sure if there's any need for it. The 3 main aspects are covered: "Core", "Hooks", "Modules" and a video demonstrating something very basic.
Regardless, as I already said, any input is welcome and I'll certainly take it into consideration. Thanks!