# Keeping ansible code and app code in sync?

**URL:** <https://forum.ansible.com/t/keeping-ansible-code-and-app-code-in-sync/22795>\
**Category:** Ansible Project\
**Created:** [October 14, 2016, 9:14pm UTC](https://forum.ansible.com/t/keeping-ansible-code-and-app-code-in-sync/22795 "2016-10-14T21:14:56Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Guy\_Matz1](https://avatars.discourse-cdn.com/v4/letter/g/b5e925/32.png) [@Guy\_Matz1](https://forum.ansible.com/u/Guy_Matz1)\
**Post date:** [October 14, 2016, 9:14pm UTC](https://forum.ansible.com/t/keeping-ansible-code-and-app-code-in-sync/22795/1 "2016-10-14T21:14:56Z")

</div>

Hi! I have some ansible code that deploys an app . . . some structure of the app has changed which is reflected in the ansible code . . . I’m wondering if anyone has some good techniques for keeping versions of app code and deployment code “married”

Thanks!!  
Guy

---

<div class="post-metadata">

**Author:** ![Renald\_Casagraude](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@Renald\_Casagraude](https://forum.ansible.com/u/Renald_Casagraude)\
**Post date:** [October 14, 2016, 10:34pm UTC](https://forum.ansible.com/t/keeping-ansible-code-and-app-code-in-sync/22795/2 "2016-10-14T22:34:06Z")

</div>

Hi!

The best mariage I see is to make them live in the same repository. Any reason why they are kind of separated for you ?

R.

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [October 14, 2016, 11:36pm UTC](https://forum.ansible.com/t/keeping-ansible-code-and-app-code-in-sync/22795/3 "2016-10-14T23:36:44Z")

</div>

Hi,

> The best mariage I see is to make them live in the same repository.  
> Any reason why they are kind of separated for you ?

a very good reason to have them in separate repositories is that your  
deployment repository contain secret things like database passwords,  
private TLS keys etc. which are required for deployment, but should not  
be included in your app's source repository.

In case you use git, you could make your app's source a git submodule  
of your ansible scripts git repo.

Another way is to keep track of your app builds in a YAML file which is  
checked into your ansible scripts repo; then your ansible scripts can  
deploy the current version mentioned in the YAML file. If you use the  
app repo's commit as the deployment tags in the YAML file you get your  
"marriage".

Best,  
Felix

---

<div class="post-metadata">

**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\
**Post date:** [October 15, 2016, 10:04am UTC](https://forum.ansible.com/t/keeping-ansible-code-and-app-code-in-sync/22795/4 "2016-10-15T10:04:33Z")

</div>

> Hi,
> 
> > The best mariage I see is to make them live in the same repository.  
> > Any reason why they are kind of separated for you ?
> 
> a very good reason to have them in separate repositories is that your  
> deployment repository contain secret things like database passwords,  
> private TLS keys etc. which are required for deployment, but should not  
> be included in your app's source repository.
> 
> In case you use git, you could make your app's source a git submodule  
> of your ansible scripts git repo.

Maybe it's just me but git submodules cause no end of grief every time  
I've worked somewhere that used them.

How about just using ansible-vault and a single repo?

[http://docs.ansible.com/ansible/playbooks\_vault.html](http://docs.ansible.com/ansible/playbooks_vault.html)

> Another way is to keep track of your app builds in a YAML file which is  
> checked into your ansible scripts repo; then your ansible scripts can  
> deploy the current version mentioned in the YAML file. If you use the  
> app repo's commit as the deployment tags in the YAML file you get your  
> "marriage".

We used that model successfully before now, except in our case a  
'deployment' would consist of 2 tags; one for the config repo and one for the  
app repo.