Tag Info

New answers tagged

0

Issues can be filtered by type, fixed version, affected version, status etc in JIRA and one can save the filter, share it with others and attach it to a dashboard for a quick overview. All the information you need is already there in Jira, if its not then QA probably shouldn't be concerned about it. Lets assume your QA team is testing one build at a time ...


3

If I'm reading your post right, it doesn't seem like this proposal actually solves either of the alleged problems. anytime I make a change to, say, myapp, this requires me to make changes to myws and mydb as well. But because each DEV environment points to its dependencies' DEV environments, it means I have to schedule and rollout these changes all ...


1

You can create a new job that only runs your integration tests. I always split up jobs like this: build + unit test deploy into UAT run smoke tests run integration tests / UAT Take a look at the plugins Build Result Trigger, and the new Build Flow Plugin. You can also just trigger another job with plain Jenkins without any plugin. In your job, add a ...


2

When you are working with multiple teams on multiple projects, you always had and will have most (if not all) of your troubles relating to interfacing between these projects. You can call it project/library/microservice/etc. - it's always the same as you describe. One team makes breaking changes, the other team(s) suffer. As this problem is quite ...


1

Use a layered architecture. Place each project in a layer, where each project is dependent only on lower layer projects, so no lower layer project depends on a higher layer project. Without layers, the dependencies become unmanageable as the number of projects multiplies. Once your architecture is layers, you test the lowest layers first, then the layer ...


0

Yes. You can put the deployment and the integration tests into two different Jenkins projects. Then you can configure the project with the integration tests to be built (executed) when the deployment build succeeds and also on a regular schedule.


0

Presumably, build 1.0.50 happened on a certain date, and any Jira tickets resolved before that date represent fixes or features contained in that build (if not, the "resolved" status is probably being misused). So it should be possible to accomplish this by making custom filters that list all tickets resolved between certain dates (and affecting v1.0). That ...


1

I've done similar things in the past. In general that plan works though you certainly want to fix the end to be "if tests work deploy to production and re run external tests" rather than rolling back if you have the infrastructure to support it. You also might want to think about versioning the api up front as a prophylactic measure. In terms of tools, ...



Top 50 recent answers are included