CI system usually becomes the world of its own, with limited number of almighty administrators, managing multiple interdependent projects at once.
This is very unusual actually.
Based on my exp, the common approach is to have an admin for Jenkins that manages permissions and plugins and lots of team leads and QA engineers who manage jobs.
From their perspective they see only "pipelines" which they created and don't see overall picture (they don't need it). And people who manage multiple projects at once appear very rarely.
There is also a new, "postmodern" way of setting up a CI, which is essentially inspired by the Travis CI and its integration into GitHub. And if we would follow the common trend, we'd call it System-less CI Pipeline.
I think, that this "postmodern" stuff is a way to simplify CI management in common layout. Travis CI, Jenkinsfile and other solutions are solutions that moved configuration of CI, that is managed by project owner into his project repo.
So the benefit here is that you as PO don't need to navigate to that CI system any more.
Intention was good, but it introduced more integration problem than has solved.
Refactoring is not a process in my opinion. Because the process has a beginning and an end, the state (works / does not work / works malfunctioning) and workload, but there is no final goal.
I would define refactoring as a set of tasks from backlog, formed on the basis of bugs, feuures requsts and developers reports, which (tasks) include activities for
- reduce technical debt (remove todo, try / pass, monkey-patch),
- improvement of the code base (code style, documentation, comments, details of error messages, etc.),
- processing of the application architecture (adaptation of the general structure so that the crutches sticked to the side began to fit organically into the application, accelerate the work, optimize for resources, etc.)
- facilitating the development and onboarding,
- acceleration of the introduction of new features,
- Correcting bugs and unlocking business features and bugfixes,
- migrating to new versions of dependencies
In this case, refactoring does not set itself the goal of rewriting the application or a significant change in its behavior.
Metrics that can be considered are
- the complexity of the refactoring itself and checking its quality,
-% of changed code base and% of affected user scenarios,
- the number of introduced bugs and degradations,
- the number (unintentionally) of the fixed bugs,
- the number of business features and bugfixes unlocked by refactoring and
- The number of business features and bugfixes blocked by refactoring.
Checklist when you can / need to proceed
- at the beginning of the next release cycle before the introduction of any features (not after the features!)
- the presence of planned features that either are not realizable, or the laboriousness of their implementation on a bad code basis is comparable to the laboriousness of refactoring and implementation on an improved code base
- bugs that can not be fixed on the current architecture
- there are problems of onboarding of new engineers
- multiple complaints about those debts from developers / testers / managers / ..
I want to mention
git rebase --onto <target-commit> <chain-start-not-incl> <chain-end-from-incl>here. This is very useful command for rebasing partial chains of commits onto other branch.
And of course git rebase interactive.
These commands are very useful for editing review branches and operating on feature branches, With the standard cost of rebasing, of course.
Q: What is the rule for feature that depends on some other feature?
Let's suppose that devs have a task for impl. some api. this feature is not yet done, but feature branch is good enough for starting to write front end.
How should devs perform branching when backend and front live in the same repo?
How should devs perform branching when backend and front live in different repos?
How do you suggest to implement integration builds and tests for these cases?
I just want to add my 2 cents.
In most of the companies CI Engineer is a Jenkins click master, a person that works hard on manual configuring Jenkins jobs by development requests.
In this community we state that CI Engineer is an Architect, Release Engineer and Principal Integrator of individual components into solid reliable releasable product.
CI Engineer is automation master with strong understanding of product, release and development live cycle.
VCS: Git Code-Review: Stash Bugtracker: Jira CI server: Jenkins Artifact storage: File Share, Jenkins Master for some jenkins installations
Stash = BitBucket Server, but this is actually marketing bullshit because even Atlassian calls it Stash in their codebase and SDKs.