(Disclaimer bash script has only been tested on Ubuntu / MacOS with docker)

Clone the repository, execute the bash script, and follow its on screen instructions.

git clone https://github.com/uilicious/dev.to-docker.git && \
cd dev.to-docker && sudo ./docker-run.sh INTERACTIVE-DEMO

Script command demo

Longer docker based commands (no git clone)

Note: You will need replace all the various <values>

# Run a postgres server configured for dev.to
docker run -d --name dev-to-postgres \
	-e POSTGRES_USER=devto \
	-e POSTGRES_DB=PracticalDeveloper_development \
	-v "<POSTGRES_DATA>:/var/lib/postgresql/data" \

# Wait about 30 seconds, to give the postgres container time to start
sleep 30

# Run the prebuilt dev.to container
# binded to localhost:3000
# Algoliasearch API key is required for dev.to,
# for login do consider adding github/twitter keys as well
# see : https://github.com/thepracticaldev/dev.to/blob/master/config/sample_application.yml
docker run -d -p 3000:3000 \
	--name dev-to-app \
	--link dev-to-postgres:db \
	-v "<DEVTO_UPLOAD_DIR>:/usr/src/app/public/uploads/" \

# Also : do give 5~10 minutes for the server to be up. 
# It does take a long time to setup and start

Docker hub link : https://hub.docker.com/r/uilicious/dev.to

Minion minion shouting joy scene

Dev.to on localhost:3000 example

Btw: I am very amused, by the various random article titles generated on a new deployment

{% github https://github.com/thepracticaldev/dev.to/pull/1844 %}

PS: if someone can guide me on how to run dev.to in "Production" mode, it would be great in improving the overall docker container performance, in such a setup.

Why do this? Isn't it possible to setup the server using the official readme ??

Well it started out with that, and ...

I failed

Its not a problem specifically about dev.to, its simply me being not a ruby developer.

All I wanted was to simply spin up a quick server, so that I can try writing some UI test scripts on it (more on that later).

I really didn't want to be figuring out how to install ruby, sorting out missing os dependencies, and fix my npm versions, trying to figure out why the existing docker build have missing images, etc, etc.......

And in the middle of fixing all that, a flashback on @ben's article from the past hit me ...

For this future where dev.to grows into a series of decentralised dev.to.like networks operated by the community to happen. We need the site to be something that is quick, and easy to deploy for anyone.

Not just someone who "needs" to know how to ruby, postgres, nodejs, or even docker and docker compose for that matter...

We already have hundreds of other more human hurdles in place to get a software adopted...

And in my subjective experience, the ability to get quick one liner demo up and running goes a long way in convincing others... Less is truly more here...

Convincing others in going beyond using https://dev.to/ itself, but to use its open source codebase, perhaps adapt it to their own needs, or more importantly contribute to it!

For homebrew users, think of how many times have you used this one line for yourself or others

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

It helps right?

The current script might not yet be there (for example we could auto install docker if its not present, and maybe in the future break the hard reliance on Algolia). But its one more step into that direction.

So what were you saying about UI testing?

What I work on in uilicious, is to run test scripts like these

// Lets go to dev.to

// Fill up search
I.fill("Search", "uilicious")

// I should see myself or my co-founder
I.see("Shi Ling")
I.see("Eugene Cheah")

And churn out sharable test result

Uilicious Snippet dev.to test

Like the above.

However there is one huge problem with it, that I am trying to solve for UI testing in general (not just for Uilicious)...

Which is getting everyone ... To run UI tests as soon as its committed - just like how we run unit tests. (be it uilicious as a development company, its customers, or any dev in general)

Because unfortunately, from what I see - majority of our users on our platform, is testing only on production. With slightly less then half having a testing/staging server. And finally, a very very small fraction testing on a git push.

Please do not test in production

In development, the earlier a test fails and notifies a developer, the better it is for everyone.

And typically the biggest hurdle in reaching there, is not just getting automated UI tests, but ...

Can you make a build in one step? : If the process takes any more than one step, it is prone to errors
~ over simplifying Joel Spolsky

Or more specifically, can you build, deploy, and test in one step?

Hence it is my small hope, that by making dev.to easier to build and run.

All I need to do next (@TODO in next article), is to chain it together with travis for temporary deployments. And finally a process where I can run UI test scripts with git pushes.

Allowing it to serve as an example use case for other dev in doing full UI testing on specific git pushes....

And maybe, maybe perhaps, convince the dev.to team to sign up for our product. or free trial πŸ˜‰

Oh, one more thing - DEV mode

./docker-run.sh DEV

dev.to dev mode

A single bash script, to help - not just with testing and demos, but hopefully dev too.

A single line command, to setup your entire dev environment from a cloned repository, and straight into bash.

No ruby/npm installation needed.

PS : If anyone have feedback how I can make this build and deploy script better / etc. Do let me know

Happy shipping πŸ––πŸΌπŸš€

This article is mirrored on dev.to
For comments and discussion please do so on dev.to instead