github.com/dahs81/otto@v0.2.1-0.20160126165905-6400716cf085/website/source/docs/concepts/collaboration.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Collaboration" 4 sidebar_current: "docs-concepts-collab" 5 description: |- 6 Development and especially deployment is a collaborative process. Typically 7 multiple developers are working on and deploying an application. It is 8 important to understand how Otto can be used in a team environment. 9 --- 10 11 # Collaboration 12 13 Development and especially deployment is a collaborative process. Typically 14 multiple developers are working on and deploying an application. It is 15 important to understand how Otto can be used in a team environment. 16 17 ## Appfiles in Version Control 18 19 First, Appfiles themselves should go into version control. 20 21 This allows anyone on the team to clone a repository and immediately 22 start using Otto to develop and deploy without any prior knowledge. Typically 23 one developer sets up the initial Appfile, and everybody on the team benefits. 24 25 The real power behind this is even people who know very little about an 26 application can easily get it up and running. For example: a designer, a 27 new employee, a manager, or even just an experienced engineer working on 28 a very old project. 29 30 ## Dependencies as URLs 31 32 [Dependencies](/docs/concepts/deps.html) are configured in Otto using 33 URLs. These URLs can be to files, GitHub, BitBucket, and more. This makes it 34 easy for one team to point to another team's application as a dependency, 35 and automatically get those updates as they occur. 36 37 In addition to this, an application only needs to specify its immediate 38 dependencies. For example if application "foo" depends on "bar", and "bar" 39 depends on "baz", then the developers of "foo" only need to know that 40 they depend on "bar". Otto automatically determines the fully tree of 41 dependencies. 42 43 Both of these features are very important for collaboration. 44 45 Dependencies as URLs keeps version control and the Appfile as the source 46 of truth. And only needing to know immediate dependencies limits the complexity 47 of working with other teams, and also gives the other teams flexibility to 48 change their dependencies without negatively affecting consumers of their 49 application. 50 51 ## Imports for Shared Configuration 52 53 Appfiles support [import statements](#) 54 to import configuration from many sources. This allows organizations to 55 create shared repositories of Appfile fragments that can be used by teams. 56 57 For example, if an organization made a standardized Ruby Appfile, a team 58 could potentially make an Appfile just like this: 59 60 ``` 61 import "github.com/myorg/otto-shared/ruby" {} 62 63 application { 64 name = "my-app" 65 type = "ruby" 66 } 67 ``` 68 69 These import fragments are downloaded as part of the 70 [compilation step](/docs/concepts/compile.html), so just like many other 71 features, changes to upstream imports don't affect a developer working 72 with Otto until they recompile. 73 74 ## Shared Infrastructure 75 76 Infrastructures with the same names (as specified in the Appfile) are 77 only created once. This allows multiple applications to share a single 78 infrastructure. Multiple teams can then deploy their applications together 79 into the same place. 80 81 Paired with Appfile imports above to share the fragment to configure 82 infrastructures, this makes it very easy to work on multiple applications 83 that are meant to co-exist in the same infrastructure. 84 85 ~> **NOTE:** Otto 0.1 doesn't support [shared directories](/docs/concepts/directory.html) 86 yet, making this point basically impossible at the time. This is a top 87 priority feature to ship in an upcoming release and will be addressed soon.