Page 1 of 1

Thoughts on Task Tracking

Posted: Wed Jan 04, 2017 7:21 am
by jyoung
I am curious if anyone is using Task Tracking and what your thoughts are on it?

Pretty much all the work I have done so far as been solo, but we are wanting to get the rest of the team involved pretty soon.
We use Gemini to track our work, so while I think the Full approach would work, the admin overhead seems like to much work as I have to maintain task state in two different places now.

We have a small team, 4-6 devs and while I thought the Minimal approach would be great, it does not seem to have a way to prevent overriding one developer's work with another. Because of that, I am thinking the Developer approach would be best. While not a fan of locking (prefer the merging with VCS) if I understand correctly, when an object is checked out it is locked and it is released when it gets checked back in. If a dev locks something and goes on vacation it can be transferred to another task but then the original "locking" dev is going to have their hands full getting their changes merged back in.

We don't really have a lot of "Products" but if you consider different applications in VLF as a "Product" and the random "It would be cool" project from management then perhaps the "Product" approach would be better... ?

I don't think we are as concerned with developer monitoring like "how much work has Joe done this month" but more of a concern is the balance of protecting the code (preventing unknown overwrites) and ease of working within the system.

What approach (Full, Product, Developer, Minimal) are you using? How is it working out for you?

Re: Thoughts on Task Tracking

Posted: Wed Jan 04, 2017 9:04 am
by atostaine
I've always preferred *U tracking, even when by myself or with 6-8 developers.

You check out and obtain exclusive lock, check in to release or you can check in and keep the lock. Stops others from overwriting changes. Definitely use repository synch groups if each developer has their own repository. I ALWAYS prefer to have my own repository.

I almost never increment my task #.

Deploying to production can be easier with other methods, but I find it simple enough to keep track of what needs to be deployed.

I worked at a shop where they had dozens of off shore people. Besides the obvious suckage, they created/changed hundreds of objects every night. I kept track by making repository lists of their tasks and IIRC sorting by last changed date.


Re: Thoughts on Task Tracking

Posted: Wed Jan 04, 2017 9:28 am
by Stewart Marshall
My simple answer here is to suggest very strongly that you use Version Control instead of Task Tracking.

We now use Version Control internally to manage the the hundreds of thousands of lines of code that make up the RDMLX portion of the IDE, and having written much of the first 150,000+ myself without version control, I'm stunned that got as far as we did without a major issue.

As you're already familiar with version control and you're using your a change control tool, it would seem counterproductive, as you pointed out, to maintain 2 sets of task state.

Version control support is available today in 14.1 and work is currently underway to improve IDE integration.


Re: Thoughts on Task Tracking

Posted: Wed Jan 04, 2017 9:29 am
by dannyoorburg

I seem to remember from your previous posts that you had a VCS setup, in which case Task Tracking won't be available to you as there's no need for it.

Or did I misinterpret that somehow?


Re: Thoughts on Task Tracking

Posted: Wed Jan 04, 2017 9:52 am
by jyoung
At my last job we had a VCS setup with Git. We used it with quite a bit of success once we got it figured out. Really only had one minor issue it which I think was due to how we where handling what gets in and out of the working folder.

At my new job we don't have a VCS option. (Yet) :D

I would greatly prefer a VCS setup, but at this point I don't know if that is going to possible.

So I am looking at the Task Tracking possibilities trying to cover all my proverbial bases.

Re: Thoughts on Task Tracking

Posted: Thu Jan 12, 2017 2:04 am
by appbuilder
If you are going to use task tracking, you should adopt it completely. What I mean by this is that you need to assign a task for every change you plan to make. This includes database changes independently of programming changes. Because of the OAM architecture of LANSA, you can update your database and if architected correctly it will have no impact on any of your other applications. This will seem a bit restrictive for your developers at first, but it will provide you with control over you software changes and how you roll them out. Your developers will become accustomed to having a task for everything and it will become part of their natural workflow. (A bit like using your seatbelt in your car. It doesn't feel right to not have it on after you use it regularly). This allows you to manage all changes and updates via your tasks.

Some will use a single task or a user based task, but with these methods, you must still track changes manually which to me defeats the purpose of doing task tracking. I want to know every object changed to accomplish any new feature or capability I add.

Good luck,


Re: Thoughts on Task Tracking

Posted: Fri Jan 13, 2017 7:13 am
by PierreLefrancois
We have used task tracking for quite a while now. It works well. We are using the full task tracking approach.

Every « change request » gets a Task Id. Objects are locked to the task until they are moved into production. We also make sure that all non-LANSA objects (images, scripts, VLF …) are defined as external resources in the repository so we can use task tracking to manage changes to these objects as well.

Export lists can be populated easily with objects from a task and that helps with moving objects to test and prod.

We use the *U task only for personal development. Each developer has one *U task assigned. This is useful when a developer needs to create test objects to experiment with.

Hope this helps - Pierre

Re: Thoughts on Task Tracking

Posted: Fri Jan 13, 2017 7:33 am
by jyoung
Don (AppBuilder) and Pierre,

I want to make sure I am understanding what you are saying.

You both mention "every change request", I assume this includes new development as well?
Each "change request", hence a task would have multiple objects associated with it correct?

Do all of the developers have access to each task or are they allocated separately? What I mean is if I have two developers (Paul and Mary) and task T0000ABC would only Paul or Mary work on that task or would you have them both able to? I can imagine this being heavily dependent on the work required to do the task but do you have any "best practices"?

If they work on the task together, how do you prevent Paul from overwriting Mary's changes or vice versa?
If they work on tasks separately, how do you deal with locking issues? Perhaps Paul goes on vacation and Mary needs an object Paul had left locked?

Thank you for your thoughts!

Re: Thoughts on Task Tracking

Posted: Fri Jan 13, 2017 8:16 am
by appbuilder
Yes, all development would be tracked via a task, including new development.
Yes, each task could have multiple objects attached to it.
We assigned the developers to the task, and yes multiple could be assigned to use the same task.

The object is locked to the PC as well as the Task. Upon check-in, you can decide if yo want to release the task from the PC or not. Multiple users may need to make changes to a component because of this lock.

You can unlock a task from a PC from the IBM i server. You will need to refresh the task via system init.

Beyond that, I yield to the master Pierre. He has much more current experience than I.


Re: Thoughts on Task Tracking

Posted: Tue Jan 17, 2017 4:54 am
by PierreLefrancois
One change request or new development gets a new task.
We try to break down development into small units so an actual change request can be implemented by multiple tasks by multiple developers.

We allow only one developer to work on a task (yes, you can authorize multiple developers on the same task but we keep that to a strict minimum because it complicate things)

There is no magic trick for locking issues. For example, Paul is working on object A and has a lock on it and Mary needs to change object A as well. In this case, Mary and Paul have to discuss and determine what kind of changes is needed by Mary and more importantly, when this is needed. If it’s a small change, maybe Paul can include it in his development. If it’s a bigger change, then maybe Mary has to wait until Paul is done before she can make the changes.

Task tracking does not solve this problem but it certainly prevents Mary from making changes to an object that Paul has already started to work on.

For vacation issues, we ask developers to check-in their latest changes to the master before they leave. So if another developer needs to work on those objects while Paul is gone, then the administrator can simply authorize the task to this developer.

Also, please note that the « release task on check-in » mentioned by Don is not possible when the « full task tracking » method is used. With the full method, the object is locked to the task until the task is « Fin – Finished » (for us, that means the code is in production).

Here’s an example of our task tracking cycle :

- An administrator (or developer) creates a task and assigns it to a Paul (only Paul).
• The task status is « Opn – Open »

- The developer starts changing existing objects or creating new ones.
• The task status is automatically changed to « Wrk – Work in progress »
• No other developers can change any of the objects contained in the task.
• Paul can check-in objects anytime he wants. This does not release the lock on the object. It simply updates the object in the master repository (good for backup purposes) and it initiates propagation to other PC’s (if propagation is activated in a slave environment).

- When development and unit testing is done:
• Paul performs a final check-in of all objects on the task.
• Paul closes the task. At this point, this means that this task is « ready to be tested » (moved to a test partition).
• This does not release the objects from the task BUT it prevents anyone (including Paul) from making more changes.

- At this point, an export/import is performed to move the code to a test partition.

- Tests are performed.

- If everything is good, then the code is moved to production and the task is set to “Fin – Finished”. This releases the lock on all the objects and they can now grabbed by any other developer.

- If problems are detected and more development is needed, then you can either reset the task to “Wrk – Work in progress” or create a new task (with a suffix like A-B-C…) and transfer the objects needing tweaking to this new task.
o We create a new task with a different suffix. For example, initial task Id is “PL001A”, if changes are needed on this task, then task “PL001B” is created and objects needing changes are switched to this task.

A note on task naming convention.
- Export lists can only be 7 bytes long(unfortunately). Because we want to create export lists with the same name as our tasks, we make sure that our task Ids are only 6 bytes long.
- The export list name for a task will have the exact same name (6 bytes). We use that seventh byte to create a second export list that holds the list itself (for backup purposes) and we name this one <taskidL> L for List.
- Our task Id’s are in format ii###s where ii are the developer’s initials, ### is a sequence number and s (suffix) is A (for first iteration), B(for second iteration). Examples: PL001A, PL001B, RM358C.
- We like prefixing the task Id with the developer’s initial. This is our preference and it works well for us. If you think that multiple developers are likely to work on a task, then adopt a different naming convention.

Hope this helps - Pierre

Re: Thoughts on Task Tracking

Posted: Tue Jan 17, 2017 6:11 am
by jyoung
Thank you Pierre for the detailed explanation.

That helps me get an idea of how a workflow can work and be able to discuss that with management and the team.

Thanks Again!