First and foremost, I’d like to tell us what the term ‘Software Deployment’ is all about.
To a layman’s understanding, Software Deployment is simply put as all of the activities that make a software system available for use.
Software deployment is, therefore the procedure of making software ready for launch.
It is the process of delivering completed software to the client who ordered it or rolling out the software to consumers.
It is also the mechanism through which applications, modules, updates, and patches are delivered from developers to users.
Software deployment should only take place after thorough testing to ensure that all the flaws and bugs have been identified and fixed, but this is not our subject matter here.
Be aware that deployment is not the last stage of the software development life cycle. The reason for this is that it is almost impossible to catch all bugs and flaws during testing. Maintenance is the final step of the life cycle, and this is when the remaining fixes will be delivered. It is also when additional features or functions might be introduced, and updates to the software made.
The software deployment processes entail:
In the preparation stage, developers ought to gather all of the code that will be deployed along with any other libraries, configuration files, or resources needed for the application to function. Together, these items can be packaged as a single software release. Verifying that the host server is correctly configured and running smoothly should also be considered here.
Before an update is pushed to the live environment, it should be deployed to a test server where it will be subjected to a pre-configured set of automated tests. Developers should review the results and correct any bugs or errors before deploying the update to the live environment.
Once an application or an update has been fully tested, it can be deployed to the live environment. Developers may run a set of scripts to update relevant databases before changes can go live. The final step is to check for bugs or errors that could occur on the live server to ensure the best possible customer experience for users.
NB: Before we let the cat out of the bag, please take note of the following:
I’ll be using my Telegram Bot (built with Ruby) as a case study :)
Ensure your bot starts and runs locally.
The steps below could also work for other Ruby bots (and not Telegram bot only) as well.
Create a file named Procfile on the root directory of the project and add the following codes as follows:
In Procfile file;
web: ruby my_app.rb -p $PORT worker: bundle exec ruby bin/main.rb
Within the project root directory, create another file called my_app.rb and add the following codes as follows:
In my_app.rb file;
require 'sinatra' get '/' do redirect 'http://bot_url_from_BotFather', 303 end
Go to Gemfile and add the snippets below:
In Gemfile, add gem sinatra;
This command installs all dependencies.
checks whether the app has been sent to the web. If the app is sent to the web, then it means the app has been deployed to Heroku.
web: ruby my_app.rb -p $PORT
checks whether the bot is sent to the worker. If the bot is sent worker, then it means the bot has been started automatically.
worker: bundle exec ruby bin/main.rb
Remember to replace
with whatever command that starts your bot locally.
does the trick on my case.
=> this line of course redirects the bot to Telegram.
Now, let’s create an app on Heroku…
from your terminal.
heroku create <name_of_your_bot>
NB: <name_of_your_bot> is actually optional. It’s required if you want your bot to have a unique url on Heroku since Heroku randomly assigns a weird url.
<name_of_your_bot> could be anything but ensure the words are separated with a hyphen (-). An example is comic-telegram-bot.
to push your bot to Heroku.
git push heroku master
instead if you’re currently not on the master branch.
git push heroku master:<current_branch>
<current_branch> is the name of your current branch.
Once you’ve pushed successfully, run
to view your app's dyno settings i.e to check if the app is sent to the web and if the bot is sent to the worker.
Remember: If the app is sent to the web, that means the app has been deployed to Heroku and if the bot sent the worker, then it means the bot has been started automatically. If everything works out fine, then both web and worker should be equal to 1.
If the web isn't 1 and the worker isn't also 1, run
to fix it.
heroku ps:scale web=1 worker=1
Remember to go to settings on your Heroku dashboard and add the ENV variable if there's any.
For instance, in my case, I have TOKEN = ‘my_telegram_API_key’ in dot.env file. So I'd want to login into Heroku. Then I’d click on the app name and go to settings on my dashboard. Then I’d click on Reveal Config Vars and of course, add TOKEN as the KEY and my_telegram_API_key as the VALUE. Then click on Add.
Once the ENV variable is added successfully, go ahead and click on Open app. This should redirect you to Telegram, ensure you click Open when it’s prompted.
Now, you can interact with your bot live and have fun without having to start it locally.
NB: You do not have to add ENV variable if your API key is not encrypted. In other words, it’s needless trying to add ENV variable in Heroku if your API key is hardcoded.
Take note of this also: The bot goes to sleep after some time, like 1 or 2 hours or so. To avert this issue, login into Heroku and click on Open app. This way, the bot would be live again.
There's actually a way to go around this, I'll definitely update this article as soon as I find a solution.
For questions, suggestions, and contributions, reach out to me on…
Create your free account to unlock your custom reading experience.