Skip to main content

An agile life made simpler with JIRA “subscriptions”

I spent more or less every working second of my day affixed to JIRA in one way or another. Whether reporting to product owners, clients, executives or even fellow engineers one way or another a question asked is answered with a JIRA query.

A great many of these questions are asked repeatedly; perhaps multiple times each day.

For these questions, there are subscriptions. A wonderful feature in JIRA that is shockingly under utilized by my peers and colleagues.

I present to you, the simple 6 step process that will surely free up some of your precious time (and patience).

 

Step One

“Search” for issues, and identify the query you are attempting to run. Typically I’m asked “how many bugs are being worked on right now?” at least once per day. A simple query that can be easily addressed with a custom search.

Step Two

Here you simply select the filter options you care about; doesn’t get much more straight forward.

 

Step Three

Optionally, you may want to customize this beyond the simple point and click solution built in with JIRA.

For example, you may want to find all bugs being worked on right now by everyone but yourself. In that case you’d click Advanced and alter your query to this:

issuetype = Bug AND status = 'In Progress' AND assignee NOT IN(jake.litwicki)

 

Step Four

When you’ve got the data you want, I’d recommend saving this filter via Save as so you can access this again on demand with your Quick Filters on the left menu. (It will appear here after saving).

 

Step Five

Separately, you’ll click Details which will give you the option to the New subscription option, which is where the money is made

 

Step Six

Finally, you customize the subscription here as desired. You can be as granular as you’d like, going to far as to customize identically to a crontab entry. Or a simple “email me once every day at 5PM” for the simple queries your colleagues ask you every day.

In either case, if you haven’t already discovered this option, you’re welcome!

Software Development Testing

Too often best practices for testing are an after-thought, or a non-thought with respect to the development and deployment of code.

This generally results in shortcuts or bandaids being applied to the SDLC of an organization which can build up over time and become a major constraint on the future product evolution.

With respect to a PHP driven application, my preference is PHPUnit. So briefly a friendly reminder to distinguish your tests by categorization, without opening up a can-of-worms on how to classify a test; we can do that later.

The simplest and easiest ways to get started with this is to organize your tests within PHPUnit, so you can run specific groups of tests along your deployment cycle.

For example, it’s generally a good practice to run your true unit tests on every commit. If they’re written correctly and concisely this shouldn’t introduce a bottleneck on the developers.

Building on that, this is a simple recommended approach for which tests to run along your pipeline:

  1. Unit
    1. On every commit
    2. After/during each pull-request being merged
  2. Integration
    1. On every preprod build; usually I do this with a jenkins/ansible build in a containerized environment that can hit specific api endpoints.
  3. Functional
    1. On every environment deployment. When deployed to env we’ll run tests specific for that environment to verify behaviors for things like billing rules, email filters, etc.
  4. UI
    1. After deployment; when deployed and “launched” we can run automated UI tests to verify behaviors and UI/UX interactions.
    2. These are typically lower importance/severity, so they can generally happen post-build.

Improve Symfony3 cache/logs performance by environment

Tired of the permission errors with your cache/logs in a Vagrant environment? Me too!

After being mildly annoyed with having to manually delete /var/cache and /var/logs repeatedly during “local” development, I decided to brut force matters into my own hands and solve this little annoyance once and for all. Ironically, Symfony 3.3 is addressing some of this, so it may be obsolete by then, but in the meantime…

What are we doing here?

  1. Define cache and logs directories for a specific environment.
    1. Wouldn’t it be awesome if we could customize these as parameters in the FrameworkBundle? Yes, yes it would!
  2. Write a simple CacheCommand that overrides the default cache:clear
  3. PARTY!!!!

Customize your getCacheDir and getLogDir methods by your environment

In my case, I typically use Vagrant/Virtualbox for local development, and Docker containers/bitbucket-pipelines for “test” while Production is a variety/flavor of AWS EC2 instances which have some additional flare.

Write a CacheCommand you can love and cherish forever and ever

PARTY!!!

Now you can enjoy life and all references to cache:clear will run your new and improved command that will also work noticably faster in Vagrant development environments; thanks entirely to Benjamin Eberlei and his wonderful blog post.

Enjoy!

cd /path/to/myapp && php bin/console cache:clear