Development Tasks

Git Branching Strategy

We’re using a slightly modified version of Vincent Driessen’s A highly successful git branching model and the associated git-flow tool (packaged in Fedora as gitflow).

Released code is kept in master and yet-to-be-released code is in develop. Generally, new code is submitted as feature branches of the form feature/tXXX-$FEATURE where XXX is the feature’s ticket number and $FEATURE is a short human-recognizable phrase to identify the branch without needing to memorize ticket numbers.

Submitting Code

Create a pull request for review on the project page: https://pagure.io/fedora-qa/blockerbugs

Once the review is complete, merge the code into the develop branch. If you do not have write privileges, this will be done for you

Release Process

The release process is relatively simple. At release time,

  • merge origin/develop into origin/master, resolving any merge conflicts or issues.

  • Make sure that the version strings in blockerbugs.spec and blockerbugs/__init__.py match and are correct. blockerbugs.spec should have a useful statement in the changelog corresponding to the changes in this latest release

  • Create a git tag on master

  • Push the changes in master and the new tag to origin

  • Build an SRPM with the new release and submit a scratch build to Koji

  • Request that the new build be pulled into infra’s repository and deploy on staging

  • After a reasonable amount of testing, deploy to production

Building a Blockerbugs RPM

Step-by-step process for building an rpm (el7, probably) for devel, staging and production.

These instructions are deliberately abstracted for version and branch so that they can be used for other things than just releases. The relevant variables are:

  • $VERSION - the version as set in both __init__.py and blockerbugs.spec

  • $RELEASE - the release as set in blockerbugs.spec

  • $BRANCH - the git branch you’re working with (master, develop, feature/t123-foobar etc.)

  • $BASEDIR - the base directory for your git checkout

Make sure that all the files you’re working on are committed in your git repo and create a tarball by running this command in $BASEDIR:

python run_cli.py minify
git archive --format=tar --prefix=blockerbugs-$VERSION/ $BRANCH | gzip -c > blockerbugs-$VERSION.tar.gz

or:

make archive

Create an srpm using mock and copy the result into $BASEDIR:

mock -r epel-7-x86_64 --buildsrpm --spec blockerbugs.spec --sources $BASEDIR
cp /var/lib/mock/epel-7-x86_64/result/blockerbugs*.src.rpm $BASEDIR/.

or:

make mocksrpm

From here, you can either build the rpm locally using mock or using a koji scratch build.

Building Locally with Mock

Run this command to build an rpm locally with mock (using --no-clean will prevent mock from rebuilding the environment):

mock -r epel-7-x86_64 --rebuild $BASEDIR/blockerbugs-$VERSION-$RELEASE.el7.centos.src.rpm
cp /var/lib/mock/epel-7-x86_64/result/blockerbugs*.noarch.rpm $BASEDIR/.

or:

make mockbuild

Building a Koji Scratch Build

The blocker tracking app isn’t in the main Fedora repos, so we can’t do official builds but we can do scratch builds with this command:

koji build --scratch epel7-candidate $BASEDIR/blockerbugs-$VERSION-$RELEASE.el7.centos.src.rpm

or:

make kojibuild

Using Alembic

Alembic is ‘a lightweight lightweight database migration tool for usage with the SQLAlchemy Database Toolkit for Python.’ and used to manage the database schema used with the application.

To install alembic, use (inside the virtualenv):

pip install alembic

To upgrade database to the most recent revision, use:

alembic upgrade head

To downgrade database back to the beginning, use:

alembic downgrade base

To upgrade database to a specific revision, use:

alembic upgrade 42d71a06dd50

To create a revision, use:

alembic revision -m "Create a table"

This will create a file called, e.g., 42d71a06dd50_create_a_table.py in alembic/versions. The file contains upgrade and downgrade methods that need to be adjusted to reflect desired migration.

In many cases, alembic is able to determine the steps needed for upgrade and downgrade through the inspection of SQLAlchemy classes. To create an auto-generated revision, use:

alembic revision --autogenerate -m "Create a table"

Building Project CSS

The CSS used is compiled from SASS using Compass. While the rendered CSS is in the git tree, do not make changes to those files if you expect them to be persistent because they are only there for convenience.

The Zurb Foundation front end framework is used as a base for a grid, among other UI elements. It will also need to be installed on the development system in order to compile the source SASS files.

Installing Required Tools

The rubygems package is needed:

sudo dnf install rubygems

Once rubygems is installed, grab the needed gems:

sudo gem install compass -v 0.12.7
sudo gem install sass -v 3.2.19
sudo gem install zurb-foundation -v 3.2.5

Building CSS

From the root of the git tree, run:

compass compile

You can also have compass watch the scss files for changes and rebuild every time a change is detected:

compass watch