A typo - cost-efficient!
But glad to see more out-of-the-box solutions coming out. It can get pretty time-consuming to deploy after your app is already done. What was the trickiest part of developing that product, I wonder?
Hey!
Thanks, I have fixed it on the landing page, evidently, I can't fix it here.
What was hard, you ask?
Short answer: the complexity of the product.
(Very) Long answer:
Yesterday I found a note in my OneNote dated Sep 2, 2016. It had a draft on what such deployment automation can be.
I was thinking about it since that time.
The first hard thing was to decide what tech I should use and what approach to use.
At first, I wanted to use "supervisord" and build everything on bare metal.
Then I understood that I should put more time into learning about docker. Everyone was saying "containers, containers, containers [balmer.gif]"
After I got familiar with docker, I've started to write bash scripts to build app, read about how Heroku works and a lot of other materials.
Then came the long part of trying to make apps build with a bunch of bash-scripts and eventually I was able to build all of my apps. I was happy and thought that I was almost ready with the app, I just need to build a frontend for that. Oh, I was so wrong.
Every new achievement that I had, every new door I was able to open led me to hundreds of new doors to open (including those I shouldn't touch). What I mean by that is after solving a problem, I found other things to solve and options to pursue.
Eventually, I got so deep in this never-ending-doors fight, that I lost my focus. My initial idea was to help deploy/run python and Django apps in the best way possible.
When I lost my focus and got overwhelmed by constant building and mountains of things I can/should build I had a slight depression.
I stepped back and given that I had some noticeable personal problems to solve I was able to switch from thinking about the app.
When I got back with a fresh head I realized that I should get back to the original focus and start to compare all new ideas and options (those doors from metaphor) to it. Is a new feature/option/idea fits for the original purpose of the app or not?
Then it all started to get easier.
Then I was able to plan ahead knowing what I should do and discarding what I shouldn't. I realized that the backlog was huge. But every single task wasn't super hard.
All this gave me peace of mind. And I started to work on it, persistently. I understood that I will not be able to ship it super fast and there are still technical decisions I will have to think thru and they also will take time. I found my pace. Every day I produced a little bit of work.
What helped was some well-known people say phrases like "it is not the matter who starts, it is a matter who keeps going". I knew that project is complex and there are so many edge cases that I should take care of. It will take time.
So, 14 months after buying the domain appliku.com (roughly the beginning of the coding) I still have the stuff to do. And always will.
So to sum this up:
- For such a complex app, I set out to build I had to figure out boundaries.
- I had to find my pace
- I had to remember that I am building exactly the app I always needed and never found elsewhere.
Generic CI/CD pipeline is a way to execute your automation. But you have to code everything yourself at least initially.
With Appliku you have your web server installed, databases provisioned and settings applied.
With CI/CD pipeline you have to write all that yourself.
You may think that one of the core features of Appliku is a niche CI/CD that has a pipeline written for you for the task of deploying and running your Python app.
Could you build it yourself? yes. Question is, should you?
Additionally, you have servers provisioning and setup, DNS records, SSL certificates issued, and many more things taken care of.
So my website is running Django 1.11 on Digitalocean.
I'm potentially interested in using your software but I'll need some convincing.
Right now updating the site is very easy. I use FileZilla to upload the new files and I would simply type `sudo systemctl restart gunicorn` once the new updates are uploaded. Also perform a `migrate` or `collectstatic` if needed.
The workflow I got right now works and is very simple, and does not rely on any middle-software.
Is there any good reason for me to use your app to deploy changes?
Let's say to deploy change I do "git push" and that's it. Everything else is done for me.
In the case with the app you described – you have already done major part of heavy lifting with the initial setup.
In your case you are not using git, it means you might have problems adding anyone else to help you coding.
Side note: if you are not using git you can easily lose your code if you don't have any other backups if the server goes down and something happens with your computer at the same time.
Now, variables, credentials: something tells me you have them in your code, which is bad. If you just add git, it is even worse – you will have them in a repo and again it is bad.
Now imagine the situation when you need to move to another server. You have all your code in the system, no containers or dockers. My gut tells me that you don't have scripts to automatically install everything on a new server. It will be a nightmare to install everything and try not to forget how they were set up(judging from the Django version it was a very long time ago).
What you have it works now, but such setup makes you absolutely unprepared for any change(new people, migration to another server, etc).
So, those were bad things I pointed out.
Let's see what (in)direct benefits of using a "middle-software":
- you will use git. It gives you a chance to add new people to the team, code history, code backup
- Your task as a developer is to git push the code. DEPLOYMENT is not exactly the concern for a developer.
- You are forced to have more up-to-date workflow. App should be tested before going out or at least should have ability to be tested. Tests are exectured by CI/CD of some sort. So you have to work in the way to be ready for that.
So, what I am trying to articulate here is that having benifits of modern tools to work in team, test the app, check code quality to eventually have better application requires certain approach to storing your code and deploying it in automated fashion. By doing it manually over ftp/sftp and manually running commands to update/restart it – you are not letting yourself to use other modern teachnologies and tools. And they are middle-software in their niche/for their task.
So, if you want better quality software of yours – you shoudl use many other things that you can called "middle-software".
When we work alone and we are not used to work with all modern tools we choose workflow that is super fast and convenient for us at that point.
I too back in a day was running production server running in "screen" and cmd/ctrl+s applied my changes and it felt logical and very easy.
What I realized that this setup is impossible to control and especially replicate. And everything falls apart when you have somebody else who needs to make changes.
Fast forward, 2020 – I don't want to think about two things: server configuration and app deployments. I want to push my code and see changes. I want to be able to invite others to my git repo and nothing in workflow should change.
When you do things manually it just doesn't happen without pain.
I hope I gave you a good enough answer, and examples and metaphors to articulate my ideas in this very huge topic.
9 comments
[ 4.9 ms ] story [ 45.1 ms ] threadWill Appliku help me with deploying my app from Github to DO?
What was hard, you ask? Short answer: the complexity of the product.
(Very) Long answer: Yesterday I found a note in my OneNote dated Sep 2, 2016. It had a draft on what such deployment automation can be.
I was thinking about it since that time.
The first hard thing was to decide what tech I should use and what approach to use.
At first, I wanted to use "supervisord" and build everything on bare metal.
Then I understood that I should put more time into learning about docker. Everyone was saying "containers, containers, containers [balmer.gif]"
After I got familiar with docker, I've started to write bash scripts to build app, read about how Heroku works and a lot of other materials.
Then came the long part of trying to make apps build with a bunch of bash-scripts and eventually I was able to build all of my apps. I was happy and thought that I was almost ready with the app, I just need to build a frontend for that. Oh, I was so wrong.
Every new achievement that I had, every new door I was able to open led me to hundreds of new doors to open (including those I shouldn't touch). What I mean by that is after solving a problem, I found other things to solve and options to pursue.
Eventually, I got so deep in this never-ending-doors fight, that I lost my focus. My initial idea was to help deploy/run python and Django apps in the best way possible.
When I lost my focus and got overwhelmed by constant building and mountains of things I can/should build I had a slight depression.
I stepped back and given that I had some noticeable personal problems to solve I was able to switch from thinking about the app.
When I got back with a fresh head I realized that I should get back to the original focus and start to compare all new ideas and options (those doors from metaphor) to it. Is a new feature/option/idea fits for the original purpose of the app or not?
Then it all started to get easier.
Then I was able to plan ahead knowing what I should do and discarding what I shouldn't. I realized that the backlog was huge. But every single task wasn't super hard.
All this gave me peace of mind. And I started to work on it, persistently. I understood that I will not be able to ship it super fast and there are still technical decisions I will have to think thru and they also will take time. I found my pace. Every day I produced a little bit of work.
What helped was some well-known people say phrases like "it is not the matter who starts, it is a matter who keeps going". I knew that project is complex and there are so many edge cases that I should take care of. It will take time.
So, 14 months after buying the domain appliku.com (roughly the beginning of the coding) I still have the stuff to do. And always will.
So to sum this up: - For such a complex app, I set out to build I had to figure out boundaries. - I had to find my pace - I had to remember that I am building exactly the app I always needed and never found elsewhere.
told you, it will be a long answer :)
Hope I have answered your question!
With Appliku you have your web server installed, databases provisioned and settings applied.
With CI/CD pipeline you have to write all that yourself.
You may think that one of the core features of Appliku is a niche CI/CD that has a pipeline written for you for the task of deploying and running your Python app.
Could you build it yourself? yes. Question is, should you?
Additionally, you have servers provisioning and setup, DNS records, SSL certificates issued, and many more things taken care of.
I'm potentially interested in using your software but I'll need some convincing.
Right now updating the site is very easy. I use FileZilla to upload the new files and I would simply type `sudo systemctl restart gunicorn` once the new updates are uploaded. Also perform a `migrate` or `collectstatic` if needed.
The workflow I got right now works and is very simple, and does not rely on any middle-software.
Is there any good reason for me to use your app to deploy changes?
Let's say to deploy change I do "git push" and that's it. Everything else is done for me.
In the case with the app you described – you have already done major part of heavy lifting with the initial setup.
In your case you are not using git, it means you might have problems adding anyone else to help you coding.
Side note: if you are not using git you can easily lose your code if you don't have any other backups if the server goes down and something happens with your computer at the same time.
Now, variables, credentials: something tells me you have them in your code, which is bad. If you just add git, it is even worse – you will have them in a repo and again it is bad.
Now imagine the situation when you need to move to another server. You have all your code in the system, no containers or dockers. My gut tells me that you don't have scripts to automatically install everything on a new server. It will be a nightmare to install everything and try not to forget how they were set up(judging from the Django version it was a very long time ago).
What you have it works now, but such setup makes you absolutely unprepared for any change(new people, migration to another server, etc).
So, those were bad things I pointed out.
Let's see what (in)direct benefits of using a "middle-software":
- you will use git. It gives you a chance to add new people to the team, code history, code backup - Your task as a developer is to git push the code. DEPLOYMENT is not exactly the concern for a developer. - You are forced to have more up-to-date workflow. App should be tested before going out or at least should have ability to be tested. Tests are exectured by CI/CD of some sort. So you have to work in the way to be ready for that.
So, what I am trying to articulate here is that having benifits of modern tools to work in team, test the app, check code quality to eventually have better application requires certain approach to storing your code and deploying it in automated fashion. By doing it manually over ftp/sftp and manually running commands to update/restart it – you are not letting yourself to use other modern teachnologies and tools. And they are middle-software in their niche/for their task. So, if you want better quality software of yours – you shoudl use many other things that you can called "middle-software".
When we work alone and we are not used to work with all modern tools we choose workflow that is super fast and convenient for us at that point. I too back in a day was running production server running in "screen" and cmd/ctrl+s applied my changes and it felt logical and very easy.
What I realized that this setup is impossible to control and especially replicate. And everything falls apart when you have somebody else who needs to make changes.
Fast forward, 2020 – I don't want to think about two things: server configuration and app deployments. I want to push my code and see changes. I want to be able to invite others to my git repo and nothing in workflow should change.
When you do things manually it just doesn't happen without pain.
I hope I gave you a good enough answer, and examples and metaphors to articulate my ideas in this very huge topic.
Wish you a great day!