Ainsofs Blog: Technology insights from the Pacific Islands

Talofa! I came across an interesting video on how enterprise software development workflows might work. I found that I was using a hybrid of techniques mentioned which aligned well given that it was showing how BIG companies with teams of developers would develop software. We have a few software developers at SPREP but mostly work on our own projects . I thought I would reflect on my workflow as it is something that I've built up over time from research and collaboration with other developers. Tests, Continuous Integration/ Continuous Deployment (CI/CD) My workflow involves setting up tests from the get go and putting them into Gitlab CI pipelines . This gives me confidence that the system builds and I'm not breaking stuff I already fixed . Here is an example of how I would set up a Drupal project with style tests and a Github Action for running them. Feature building with Git branches I build features using git branches . If I have an urgent requirement or fix , I can switch ...

  SSH ports Self hosted Gitlab normally uses port 22 for SSH access. When running docker this is not ideal as its usually used by the server. Its best to map it to another port. The Gitlab docs provides an example of using port 2224. Gitlab Web UI booted up great! But I could not clone or push to the repos using port 2224. First this port is blocked by my organisations firewall. Using online tools I checked if it was accessible outside of our network. Nada! We proxy our traffic using Cloudflare. To get it working, I used one of the allowed non-caching ports. This allows me to have my Web UI proxied but still have access to SSH for git cloning. There are other options available . Server specs I used a cloud server and initially set the specs too low. Ensure to check the minimum server requirements before selecting your specs. Boot time Although docker compose reports that the container is running as soon as you issue the docker compose up -d command, it takes a while f...