Heroku button = painless deploys

This Friday I made a few things I think are cool. One was a Dockerfile for a piece of software called indielogin.com, the other was a Heroku deploy button for the same software.

I am a firm believer that one of the best ways to learn, is to get something working. My plan was simple:

1. Download the software source (it is written in a scripting language)
2. Build one or more docker containers using the scripting runtimes
3. Try to get project to work (without services) in a docker container
4. Fill in services using docker-compose
5. Throw at Heroku and iterate through remaining issues
6. Refine solution
7. Adjust documentation
8. Ask for feedback

Initially I was frustrated because I re-used some code I maintain, which is used to test PHP libraries & project test suites across PHP runtimes. I would forgotten that the software I maintain, is designed to avoid baking software into docker images. A pattern CloudFoundry does not cater for. This was not the only problem; another was that it is built for a local, or internal CI systems, not public web.

Due to this I had to change course to ensure the built Docker image contained the code. This could introduce its own challenges.

• The feedback cycle being longer
• The need to build an image every time you want to try modification or new code.

I overcame the cost of the feedback cycle, by having docker-compose mount the present working directory to the same path as the baked Dockerfile code deploy directory. This means I can change a file and locally get immediate feedback without restarting the container, building a new one, etc.

I accepted that this would push deploy times if locally pushing updates. My primary focus for using this technology is for preview branches and to get people quickly spun up as users of software, rather than maintainers. I opted to avoid the needs of a package maintainer.

I Had a few challenges around logging and code-style of the author, and lack of environment-based source of facts common in cloud-native applications, but overall I am very impressed with how easy it is to deploy Cloud software to Heroku in 2019.

Retrospective

While I am sure I will not win awards for my work, it may even be short-lived and not be the best long-term solution, it does provide some options. "what if you did this?"

Missing technical fulfilment such as the multi-runtime support; I am happy for others to iterate on.

I remain confident my work is straightforward enough that others can learn from it and use it in my absence.

The experience really helped show off how mature software deployment has become since I started writing software in the late 1990's, where a week was considered a short deployment for complex interconnected software.

It made me happy that I was familiar with challenges that presented themselves, technologies' the application used, and it helped me to gain confidence in a platform I don't use much and grow my understanding of its ecosystem.

I feel that I now understand more about this emerging system and the IndieWeb than I did before starting.

I remain aware that there are things I might change. I am confident others can combine wider skills and know-how in this proprietary platform to leverage non-vendor specific knowledge.

I would like to further build on skills from this work to deploy branch-specific builds, perhaps using shared infrastructure, or using repository pattern to avoid service-boundaries altogether without disrupting live environments.

I have a greater appreciation for the outcomes of beautifully crafted platform as a service.