I am localizing an application however I have challenge in designing the translation and deployment process. After the initial release, we will maintain a daily deployment to production. However, when a developer introduces a new string which needs translation,
should I halt the merging of that PR, unless the translations are completed and also checked in the same PR. This is not the best developer experience.
should I merge the PR and deploy to production. Meanwhile, the string will display in the default language in some cases, unless the translations are available for all supported languages. This doesn't seem like the best customer experinece
should i merge the PR and keep the feature behind a feature flag, unless the translations are checked in for that string. However, this will introduce a lot of feature-flag overhead for each new page or section of page.
This situation is unique to me, so looking for suggestions.
Related
From a "process controls" POV, in a continuous delivery/deployment context, how important is it to mandate that source control commits are associated with an Agile PM (or ticketing tool) "work-item?" Here "work-item" means any of: user story, task, defect, bug, etc.
The end-goal is to ensure that developers are not placing new features into production that were not derived from the product owner. Obviously code reviews are a critical part of a proper process-controls story, but having a code review presumes the reviewer can look at the associated statement of work (e.g. user story) to ensure the code changes reflect the requested work.
Herein lies the issue.
Context
I've always assumed to have a workflow where work-tickets are associated with commits, such as with Jira, but now I'm working with a corporation whose PM tool is incapable of associating work-items or defect-tickets with source commits.
With this client, I'm also seeing a catch-22. First, I'm told by representatives of the PMO that such ticket-to-commit associations are not needed. Second, the engineering org paid for an outside consultancy to audit and flag major process flaws. The #1 flaw that was identified was the inability for management to know if developer commits have any bearing on authorized work.
From my POV, I think the PMO needs to realize that they are the "tail wagging the dog" and that they need to embrace tooling changes or special integrations to overcome this problem (not to mention more maturity with Agile philosophy).
However, perhaps I'm the one who simply is over-concerned about the ticket-to-commit associations, and perhaps there is another way to achieve effective process controls without that particular mechanism?
When dealing with regulated industries, such as health care or governing bodies, full traceability from scope to code is a requirement. I once had to perform an audit to validate that every line of code correlates to a line in the SRS for FDA approval, although generally it's enough to demonstrate that there exists a method of traceability (such as a branch in github that is named to match a task / story in JIRA and code integration is enabled).
If you're not in a regulated industry, requirement-to-code traceability is not a requirement... but it is still immensely helpful. The advantages include, and are not limited to:
Full transparency to everyone on the team, tech or not. The amount of confidence that this evokes is amazing, and the amount of chatter it reduces.
Reports to identify what theme in the requirements are causing the greatest amount of code churn, because there's a heavy cost to that.
Identifying features affected by a PR. This is immensely helpful when a release is planned, some aspects of the release are unattainable or buggy, a lot of the code has already been merged, and the team needs to isolate what to release and what not to.
Confirmation of an opinionated truth by remove the opinion: "I'm sure I did it... let's double check... yup! (or oops, let's rectify that!)". This helps deter CYA behavior, which is drain on morale and negatively influences efficiency.
Simple implementation with existing mainstream toolsets (JIRA, Trello, Asana, Freshdesk for tickets... Github, Bitbucket for repo and tickets... Zapier, IFTTT for integrations across systems that lack built-in integrations)
For every team I have ever managed or established (as dev manager, PMO, product manager, consultant or founder), it has been my explicit expectation that every line of code can be traced to the requirement for the reasons listed above. I advocate implementing this using the branch-per-topic pattern in git (Github or Bitbucket), where the branch is prefixed by the JIRA task/story/bug (eg. XYZ-2443-fix-that-bug) so that JIRA's integration automatically displays a link of the branch to the issue.
Of course, this is not the only way, but it is my preferred process at this time and is meant to illustrate a concrete example.
My team is asking me to add all these states in the PBI workflow.
New,
Prioritization,
Design,
Business Review,
IT Review,
Approved,
Committed,
In Development,
Development Done,
QA Testing,
Ready for UAT,
Released to UAT,
UAT Testing,
Available in UAT,
Ready for Production,
Released,
Reopen,
Resolved.
I know that we can accomplish the same by using Tasks or Reason field and we have to keep the workflow "Simple" but my team is insisting to track that using a single field (State) so that it is clear. I would like to know if it is a good idea.
I appreciate your thoughts and feedback.
We can't say how many states are reasonable or best. TFS is extensible and customizable, it is designed for customers will be able to meet the needs of the organization.
But as we know, the more states you define, the more transitions you must define. The maintenance and further upgrades will be more complex. Changing the workflow states of work items, specifically those in the task and requirement category can cause unexpected challenges in existing functionality as well as future upgrades. Changing to requirement types (Product Backlog Items and Bugs for Scrum, User Stories for Agile and Requirements for CMMI) will require modification of the Agile or Kanban board. They will also most certainly prevent an automatic easy template upgrade.
Customization should be well-thought out, instead of changing the existing State field, you may consider add a new "customStatus" field which won't impact existing reports and upgrades.
A good blog for your reference: http://blog.nwcadence.com/tfs-customization-pitfalls-payoffs/
This is another option for you to think about but you don't necessarily need to amend the states. You could use Board Columns which can be set on the Kanban board. With each column, you can optionally choose to split containing a Doing and a Done which could mean you require less states.
You can then query on Board Column instead of State
I was in a similar scenario to you when setting up our TFS (although not with as many states requested!) and I ended up going with Board Columns. Here is ours, it seems to work for us:
All of these have no split with the exception of In Development because when development is done it is not necessarily ready for test.
This functionality came with TFS 2015 Update 1 so you would need to upgrade if you're not on that version.
Here is how we use each state:
New - New PBI or Bug
Approved - Confirmed the work will be done and complies with the DOR (Definition of Ready)... (Contains enough info, priority assigned, tasks created, test plan created etc)
Committed - Assigned to a future sprint
In Development - Contains a Doing and a Done
In Test - QA
Ready for Release - Signed off and ready for release
Done - Released and DOD (Definition of Done) has been completed.
I have a problem, I have several versions of the same application but the process of duplicating and managing several duplicate applications is becoming very complex, each copy gets unique features by client demand.
What methods are used to simplify this process?
Do I need to have detailed documentation about every App?
I'm trying to separate the code by modules and had them according to the clients demand, am I on the correct path?
Sorry for the bad English, any question just ask, I'm always online.
This can be managed in your code revision system. Git and Mercurial allow you to manage code as "change sets". You could have a branch for each client, and have a main branch (trunk) where you add features for everybody. In the client branches, you add feature sets for individual clients. If you want to merge them back to the trunk, you can. You can also merge from the trunk to branches.
Of course, it's important to develop in a modular way in order to facilitate this approach. Also, unit tests speed things along when you have to merge.
We are considering using Gerrit for the large project. At this point it would be interesting to know how people are dealing with merge conflicts of approved changes.
Imagine, that many changes of different size are pending revision simultaneously, and they are being reviewed and verified gradually. Since some of them might be modifying the same piece of code, the conflicts are inevitable. It is not a problem if "integrator" accepts patches manually in a simple workflow, small conflicts can be resolved on the way, but with Gerrit things are different. When the change has been reviewed and approved, in case of merge conflict, as I understand, it will need to be rebased by the author and pushed for revision again, in which case revision process starts again. In the relatively active projects, with more than 50 external contributor commits per week, this might turn into nightmare, if revision of the same patch might be required to be done several times due to merge rejection after each approval and submit, which seems to be not efficient.
Questions:
Am I correct that Gerrit is not a way forward for the large and active stuff where the large number of merge conflicts is expected?
Some merge conflicts can be trivial, is there a way to resolve them without the need of bothering author to recommit the change?
If the change needs to be backported to stable branch(es), I guess the separate change for each branch needs to be pushed for revision, even if the cherry-pick is clean.
General comments about your Gerrit workflow experience are also welcome.
Gerrit is used by some really massive projects, such as Android and the related bsp, kernel, etc repositories. These projects get way more than 50 external commits per week. I think Qualcomm will have several thousand commits in about that amount of time.
There is a setting in Gerrit to auto-merge trivial conflicts. This can be set per-repository. If this option is set, the change is merged in based on your submit strategy (cherry-pick, merge if necessary) after the change has been reviewed and verified and a user presses the 'Submit' button. The best documentation I could find for this is here http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options under the --use-content-merge option.
Yes that is typically how we do things. There are other options (bypassing review, merging branches, etc), but cherry-picking to the needed branches and reviewing works well.
We want to keep our history clean and understandable, and therefore reasonably linear. So we have configured Gerrit to use only fast-forward merging. The only visible merges are for release and support branches (we're using git-flow) which makes things much easier to understand.
However, we have the trivial-rebase plugin installed so that previous review status is automatically applied to the rebased change. This happens regardless of whether rebasing is done in Gerrit (using the Rebase button) or by the developer rebasing locally and re-pushing the change.
In our experience, merge conflicts are actually less common in a large project, due to the much larger number of source files involved. We have around 16,000 files in the repo and 30 full- or part-time developers, so the probablility of editing the same file is quite low.
In any case, if two developers are making changes to the same part of the same file, they really should be talking to each other. If the project architecture requires frequent changes to the same file (eg a registration table of some kind) the architecture needs to be redesigned, to use something like dependency injection, or to generate that source file automatically from fragments as part of the build.
When we hit a merge issue at our company, the developer rebases and pushes to gerrit. If the merge was minimal, he's allowed (by convention) to LGTM the rebase and submit.
We are still debating if/when developers should rebase when updating patchsets. The UI gets confused when comparing between patchsets when the parent changes.
I'm using it for a few weeks after using mercurial for a couple of years with a feature branch merged into default mode and I'm hating gerrit. I find myself with more overhead solving trivial conflicts that are solved automatically by merges on mercurial or git in non-gerrit mode. Then everybody uses the argument android uses gerrit ergo gerrit is good and should work for everybody.
I know there is a lot of talk about BPM these days and I am conscious that some may see it to be a craze rather than a fundamentally important piece of software.
As someone from what most would call 'The Business', I have been doing my best to learn about BPM to ensure we continue to make decisions that not only make sense to the business, but IT as well.
I have noticed while reading that mention is made to application workflow when sometimes discussing BPM. I hadn't given this much thought until recently.
Therefore, what is the difference? When would you use one and not the other?
BPM is about the process and improving it, which takes into account users and potentially more than one application,e.g. an ERP system may have more than one application to it, though there may be other uses of the term. Note that the process could be viewed without what applications or technologies are used.
Application workflow is how an application is used to go from a to b. Here it is a specific set of code that is used and what happens over the course of an application getting from a to b. In this case, the application is front and center rather than the process.
Does that provide an answer? Another way to think of it is that multiple application workflows can make up a system which is used in a process that can have BPM applied to it.
Late to the game, but workflow is to database as BPMS is to DBMS. (Convenient how the letters line up, huh?)
IOW, BPM(S) is traditionally meant to refer to a particular framework/application that allows you to manage business processes: defining them, storing them, versioning them, measuring them, etc. This is similar to how a DBMS manages databases.
Now, a workflow is a definition, much like a database is a definition. In the former case, it is a definition of operations/work (Fufill Order), steps thereof (Send Invoice) and rules/constraints on the work (If no stock, send notice). In the latter, similar case, it is a definition of data structure (CREATE TABLE) and constraints (InvoiceTotal must be > $0.00).
I think this is a potentially confusing subject, particular as some development environments use a type of process flow model to generate user facing applications (I'm thinking about Outsystems here, for example).
But, for me, the distinction is crystal clear. Application workflow, as people talk about it, refers to a user's path through an application, i.e. the pages they complete/visit, the data they enter, etc. on their way to completing a transaction of some sort. Application orkflow is a poor term for this though, I think application flow would be more meaningful.
BPM on other hand, is about modelling and executing a workflow process. By workflow, in this context, I mean a series of discrete steps (or tasks) that have to be completed (either programmatically or via human interaction) in a certain order to complete a process. These tasks can be implemented as individual application modules (each with their own "application workflow", see above). The job of the workflow engine is to make sure that these separate steps are assigned to the right people (of groups of people) in the right sequence, and that overall the process completes in an orderly way.
I don't think there's a clear answer to this at all. These are words, as opposed to theoretical concepts. If you add the word "checklist" into the mix - that just turns out to be a linear version of a process (but you can have conditionals in checklists - making them a workflow).
I am not sure how to help in reframing this question, but it's almost as if no answer can ever be possible. My own thoughts are at https://tallyfy.com/improving-efficiency-workflow-vs-business-process-management/