3 ms·

You can write glue for whatever hosts your repository to make api calls to Jira. Say you have some code that needs some changes but at a later time, you can pu

You can write glue for whatever hosts your repository to make api calls to Jira. Say you have some code that needs some changes but at a later time, you can put a comment above it (or really anywhere) // JIRA: MYPROJ-123 When the glue sees that comment disappear from the codebase, it can mark the ticket as done.

marcus_holmes 3y ago
Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around. The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.
- Tainnor 3y ago
  What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.
  - superice 3y ago
    Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.
    - marcus_holmes 3y ago
      yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting... edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.
    - Tainnor 3y ago
      Sure, but then you have to tag those tests with the ticket, and GP didn't want to have references to JIRA inserted in the code. The other problem is that you still need to track when all the tests for the feature have been written.
usrbinbash 3y ago
The code is the model. The project management system is the view. The model shouldn't have to change to accomodate the view.

marcus_holmes 3y ago

Useful, I guess, but that seems to be inverting the responsibility. The code needs to have comments inserted into it referring to the state of Jira, rather than the other way around. The thing I'd like to see is that ticket "Write the login page" is automatically marked complete when the codebase contains a working login page, there are unit and integration tests for the login page, and maybe (depending on how you do your documentation) a set of comments on the API methods involved describing their use in the login process. All without those code elements ever needing to know the ticket exists.

Tainnor 3y ago
What you're describing looks like magic to me. How would your ticket system know, without it being told (in some way, e.g. through backreferences from the tests), that a particular feature has been implemented? That's very likely going to be a formally undecidable problem.
- superice 3y ago
  Writing end-to-end UI tests to validate a certain behavior and then automatically resolving a ticket once those tests pass seems really cool though. Not sure how realistic in practice, but it's definitely an interesting concept.
  - marcus_holmes 3y ago
    yeah, something like TDD but the ticket is actually a set of integration or end-to-end tests that must pass for the ticket to be "done". Hmmm, interesting... edit: actually, thinking about it, you could do plain TDD and track the tests as the tickets. Write all your tests for the project first, then track how many are passing as the progress measure.
  - Tainnor 3y ago
    Sure, but then you have to tag those tests with the ticket, and GP didn't want to have references to JIRA inserted in the code. The other problem is that you still need to track when all the tests for the feature have been written.

usrbinbash 3y ago

The code is the model. The project management system is the view. The model shouldn't have to change to accomodate the view.