Managing Maintenance and Updates

Several things will probably need to be managed and handled after publishing our app, and we’ll cover a few of them.

Fixing bugs and making changes

This should follow the same workflow we established at the beginning of this section. Any changes to our code, whether bug fixes or additions to our functionality, should be done the same way. We edit code locally, make sure it is running correctly, and then push to the central Git repository. Then, from the server, we pull the changes and rerun the app.

Updating Python packages

There are several packages that our app depends on, and you will most likely have even more in your daily work. Those packages will release updates every now and then, and we need to make sure that they are up to date. Some of those updates are security updates and need to be handled as soon as possible while others introduce new options to packages. In general, we can run pip install --upgrade <package_name> to achieve this, but we’ll still need to check if the new functionality might change the way our app is running or whether it will break our existing code. Well-maintained packages usually publish any such breaking changes and also provide instructions for upgrading, if needed.

Once we have decided to upgrade packages, we can run the upgrade locally to first test our app and make sure it is running with the new version, as follows:

1. From the command line, go into the app’s folder on our local machine, as follows:

   cd /path/to/your/app
   

2. Activate the virtual environment, like this:

   source /bin/activate
   

3. We should now see the name of our environment in parentheses (env_name), and we’re now ready to upgrade the package of our choice, as follows:

   pip install --upgrade  <package_name>
   

4. Assuming everything went fine, we run our app, and make sure it is running as expected by executing the following command:

    python app.py
   

5. If everything went well, we now need to update our requirements.txt file to reflect the new version of the package and possibly modified versions of other dependencies. We first use the pip freeze command. This takes all the available packages in the current environment, as well as their dependencies, together with the right version number and prints them out to stdout. Now, we want to take this output and redirect it to the requirements.txt file to overwrite it with the updated requirements. We can do those two steps in one go, but it’s good to familiarize ourselves with the output of the first command first, which can be seen here:

   pip freeze > requirements.txt
   

6. Commit the changes to the Git repository and push to GitHub. The git add command adds the file(s) to the staging area, which means they are now ready to be added to the history of the repository. The next step is to commit those additions with the git commit command, which also takes a message in which we state what has been done. We then submit the changes to the online repository with the push command, as follows:

   git add requirements.txt
   git commit -m 'Update requirements file'
   git push
   

7. Now that we have the latest requirements.txt file on our central Git repository, we can pull it to our server, just as we did in this section. After logging in to our server, moving into our project’s folder, and activating its virtual environment, we can pull the changes. The git pull command does two things. First, it fetches the latest repository changes from the remote server. Then, it merges the changes into the local copy, and we get the updated app. The command is shown here:

   git pull
   

8. The change we fetched and merged in this case was the updated requirements.txt file. We now run the following command to install our packages on the server using the new versions:

   pip install -r requirements.txt
   gunicorn app:server
   

This should start our app again with the latest updates included. While we changed the requirements file in this case, we could have also changed the app’s file or maybe added new data. Whatever the change, this is the general cycle that we go through to incorporate those changes.

Now that we have a new component to handle—our server—we’ll also be managing and maintaining it as well.

Maintaining our server

The following list provides a very brief and oversimplified set of things without instructions. The proper way is to learn more about Linux system administration, but these are likely things we’ll want to manage and can easily find guides and documentation for: