Disclaimer: original ansible author here and I run engineering for AnsibleWorks. First off, ansible itself (which this post is about) is text based. I assume you're talking about AWX, which is coming out shortly in 1.4 form, which is our commercial server -- UI and REST API. (Ansible core is decentralized and doesn't even need a server installation).
AWX is designed around team workflow and wants to be the central hub around your automation tasks. i.e. how do you control who can access what, who's doing what, and make things push button in the hands of people who might not be the ones writing the content. You can delegate the ability of lab staff to manage inventory, but not allow them to deploy software, or let them only deploy specific projects, etc. Same for Dev vs QA vs Ops teams, etc.
I definitely don't think it's something everybody needs, but it's available for those that find it useful, and definitely recommend everybody try it out. In the last release, we added some nice source control integration features so you can still develop in your editor and retain the ability to have the web console and central logging. In the upcoming release, we do some neat things with graphically syncing cloud inventory and provide some bonus console information that is useful if you are working with teams who want to know what's been going on where, and it improves the ability to quickly drill down and see what parts of your infrastructure might need attention.
One of the other features is it's ability to hold onto credentials, so you can share source control, machine access, and other credentials with your team without them needing to actually know those credentials.
If you remove someone from LDAP, they can cease to have access.
Anyway, it's super important that we don't hold ansible core back, so what's going into the product is largely around team workflow, and things that automate workflows in Ansible, just like how Ansible automates your system. It's intended to be able to hand Ansible to other people -- and work better in your overall team context, even people who don't want to be writing playbooks. If you're a 1 or 2 man shop, you might not need it, but try it out anyway and let us know what you think!
Also, here's a blog post about the 1.4 Ansible release, which explains the changelog at a bit higher level:
Disclaimer: original ansible author here and I run engineering for AnsibleWorks. First off, ansible itself (which this post is about) is text based. I assume you're talking about AWX, which is coming out shortly in 1.4 form, which is our commercial server -- UI and REST API. (Ansible core is decentralized and doesn't even need a server installation).
AWX is designed around team workflow and wants to be the central hub around your automation tasks. i.e. how do you control who can access what, who's doing what, and make things push button in the hands of people who might not be the ones writing the content. You can delegate the ability of lab staff to manage inventory, but not allow them to deploy software, or let them only deploy specific projects, etc. Same for Dev vs QA vs Ops teams, etc.
I definitely don't think it's something everybody needs, but it's available for those that find it useful, and definitely recommend everybody try it out. In the last release, we added some nice source control integration features so you can still develop in your editor and retain the ability to have the web console and central logging. In the upcoming release, we do some neat things with graphically syncing cloud inventory and provide some bonus console information that is useful if you are working with teams who want to know what's been going on where, and it improves the ability to quickly drill down and see what parts of your infrastructure might need attention.
One of the other features is it's ability to hold onto credentials, so you can share source control, machine access, and other credentials with your team without them needing to actually know those credentials.
If you remove someone from LDAP, they can cease to have access.
Anyway, it's super important that we don't hold ansible core back, so what's going into the product is largely around team workflow, and things that automate workflows in Ansible, just like how Ansible automates your system. It's intended to be able to hand Ansible to other people -- and work better in your overall team context, even people who don't want to be writing playbooks. If you're a 1 or 2 man shop, you might not need it, but try it out anyway and let us know what you think!
Also, here's a blog post about the 1.4 Ansible release, which explains the changelog at a bit higher level:
http://blog.ansibleworks.com/2013/11/21/ansible-1-4-released...