figure out deployment process

[rahulbot]

Now that we have a containerized server running, we need to figure out who/how to management deployments. I'm sure you've thought about this already, but I want to spur the conversation again as part of this new server transition.

Technically, there needs to be someone that has ssh keys set up to run a git command on their local machine, that rebuilds the container on the server (much like Heroku). I'm happy to do this in the short term (if releases aren't very frequent).

Socially, there needs to be some process for deciding when to deploy code. What have you done previously for this? Who decides this now? A lightweight process would involve developing on master, or feature branches from it that get merged back when ready, and simply git tagging the repo when it is ready to deploy. A more involved process involves having multiple branches and releasing to production from a "production" branch, working on new stuff on a "development" branch, etc. That feels a little heavyweight for this project.

To support any process you decide on, I suggest adding a version number somewhere in the source code that renders in the footer of every webpage - it can be very helpful for quickly determining which version is running where. incrementing this version number can be part of the pre-deployment process because tagging a commit with that version number (whether it uses semantic versioning or not).

[numeroteca]

I don't think we are going to have frequent releases.

For the moment it's me organizing development and deciding when to deploy. Once in a while. Nevertheless, I hope this process enables better and more frecuent deployment.

I think that the lightweight process you describe is the way to go: developing in master or in branches and merging to master and tagging those versions. We are using tagging also for the docker images that are built automatically when we tag a version. @rporres will explain better how that works. I don't know if the process can be totally automatized for deployment.

See releases: https://github.com/montera34/pageonex/releases

Good idea about adding the version to the source code, I've added it to the footer dce9916.

We can organize a call to talk decide about this if we can't find a solution here.

I am copy-translating-pasting here and chat I had with @rporres about this process a while ago:

1. When you create a release it internally creates a tag in the repo https://github.com/montera34/pageonex/releases/tag/v0.0.1-rc1

2. As the repo is connected with Travis through WebHooks, GitHub sends what is going on in the repo.
   These are the builts in Travis: https://github.com/montera34/pageonex/settings/hooks/62926918
   Depending on the configuration in .travis.yml different things are being done. In our case: when we create a tag a container is created.

3. This is the build log of Travis https://travis-ci.org/montera34/pageonex/builds/454511196
   and here you can see how two new tags have been uploaded: (log in needed, see image) https://cloud.docker.com/u/pageonex/repository/docker/pageonex/pageonex/tags
   One has the tag we've provided and the other points to the repo latest (a Docker standard to have always the latest).

Screen of cloud.docker.com that we are using:

[rahulbot]

For this container I build from the source code, not the docker image, but that's so cool that you have that there an a ready-to-go thing. Sounds like for now you can just let me know when you want to push a release to the dev or prod container servers - only takes me a minute to run the git command. With infrequent releases that shouldn't be a bother for me.

[numeroteca]

so, I'll ping you @rporres to know which steps to follow everytime I want to move to a new version.

[rporres]

As long as there are commands to run, the process of deployment could be automated from Travis to also deploy when a tag is created on master. What worries me of doing that is what happens if something goes wrong...