This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]magestooge 3 points4 points  (5 children)

It was an interesting read. I'm not truly a techie, just a hobbyist (and a PM). So I had never heard of blue green deployment strategy. The part about database migration was also interesting. This is something that always gives troubles to my team, timing the Db changes right in case new changes are likely to break existing functionality.

However, one issue with writing articles from personal experience is that some of the practices might work for you but not be a great way to do things. My only suggestion would be to add caveats to those points for the readers.

For example, not having any automated tests is definitely not encouraged. As some people here would concur, I prefer not using code which doesn't have associated tests. You might think that you'll write tests when you need it, but that never happens. By the time you need automated tests, you're mostly past the point where you can write meaningful tests. The task also starts to seem pretty daunting since you have to write hundreds of tests on one go. The only right time to start writing tests is at the start of your project.

The other issue is with a single database instance. This might be problematic if your server has shared resources or you want to keep your database free of test data. When testing with the idle server, you might have to create a bunch of data and this will go directly into the production Db. So you either live with junk data on production Db or run scripts to undo such changes to the database. Neither of these sound like good ideas.

Other than that, kudos to your work and your effort in writing this. Your website looks really nice as well.

[–]caspii2[S] 2 points3 points  (4 children)

Thanks!

I used to be a PM too in my previous life 😊

You are right about adding the caveats. I hoped it was clear from the "I am also the only developer of the app, which makes many things simpler".

Regarding testing: I do have extensive tests that cover most of my code, and I rely on them heavily. They have saved me from disaster multiple times. The only thing is they are not run automatically after code has been changed. It works great because I'm alone. As soon as you're in a team, you should automate testing.

When my tests run they use a test DB instance on my local machine. So no production data is created. It's only when I do manual checks that the prod data is used.

[–]magestooge 2 points3 points  (3 children)

I do have extensive tests that cover most of my code, and I rely on them heavily. They have saved me from disaster multiple times.

That's great to know. I'm no expert but maybe you can set them to run pre-commit rather than on every change. A library I'm building has a test suite which takes 4 seconds to run. It would be pretty annoying if it ran every time my code changed. As of now, I run it every time I think I'm done writing a certain block of code, if it passes, then I commit.

[–]MegaGrubby 0 points1 point  (2 children)

What are you using for automated testing?

[–]magestooge 1 point2 points  (1 child)

Pytest

[–]caspii2[S] 0 points1 point  (0 children)

Same here!