We're working on an application that is being used by multiple customers, each having a different version of the app.
Our team is currently following the Git Flow branching strategy, but we've been hitting a wall on maintaining a single master branch.
For example:
Customer A has v1.1.2
Customer B has v1.1.4
We have fixed a vulnerability for Customer B in v1.1.4, and updated the version to v1.1.5 in the master branch.
Now Customer B has asked for the patch fix in their version, but does not wish to update to v1.1.4 as of yet.
This fix then gets versioned as v1.1.2.1 (still on its release branch).
We are currently maintaining multiple release branches and pulling in feature branches in as needed, but we feel this isn't scalable in the long-run.
Is there a recommended solution or branching strategy for this?
Maybe you should create release every x.x.x version also fix your bugs on x.x.x.x versions and your customers can use this versions.
So there can be many x.x.x version. You can think this x.x.x versions are kinda major.
Did you tried looking for oneflow approach where you create the new branch from previous release.
Try having a look in this https://www.endoflineblog.com/gitflow-considered-harmful
There are two main updates - new features and security updates. The new features can be maintained per customer as per the version numbers. However, the security updates can be given as a patch that is available from v1.x.x onwards. This would decouple the vulnerability fixes and the feature updates. You could put the patches in a specific branch and someone could merge their given branch with the latest on the security patches branch.
You could send an email everytime there are new security patches.
My suggestion is to move your Softwares components to multiple seperate repositories.
You can then include them as subrepositories in different states in the different branches/repositories (you would have tp create a branch or repo for each customer).
Related
I use Bamboo regularly as a QA tester to deploy pull requests and feature branches/release branches, but I'm not a developer and have a layman's understanding of how it works.
Our Bamboo configuration is set up to remove inactive branches after a certain amount of time (2 weeks) which happens pretty regularly with longer-term projects, unfortunately. (When that happens, I do know how to configure a new plan and run a new build.) Often, with these larger projects, they've been deployed manually many times over the course of the project, resulting in a large list of possible "release" versions when I go to "Promote existing release to this environment."
Now, I have a brand-new build of a brand-new plan for a project I've been working on off and on for a year and I would like to delete all these old builds (releases?) that show up in the dropdown when I want to just deploy the current version of the current new build, but I can't figure out where to do it (neither can the devs I've asked, but it's NBD to them, whereas this is a constant annoyance for me).
All the advice I can find online says things like "all builds are automatically deleted when the branch expires ...." and that doesn't seem to be true, because these are definitely from old expired plan branches. They also explain how to delete things manually .... from an existing plan branch, which I don't have, because the older plan branches expired and were removed.
Am I using the wrong terminology here and these aren't "builds" and there's a separate way to delete them? Do we have a setup that's failing to delete them when it should? Do devs need to do something different with their branches? I obviously don't have access to global settings but I could put in a request if that's what needs to change.
To be clear, I'm talking about going to deployment preview, selecting "promote existing release to this environment," entering in the jira number/beginning of the branch name, and seeing a million of these (which all look identical because our branch names are hella long):
deployment preview screenshot
I have read through all the Bamboo documentation relating to plans, builds, branches, and deployment, and Googled various combinations of relevant keywords and haven't found a solution. I've also asked devs I work with and they don't know either.
How to prevent checking out / changing one binary file in different branches of the same content. Situations like: designers have edited some game level (*.umap binary file) in their branch. Programmes changed same file in their branch (for example - added some blueprint on this game level). So now we have three different versions of this file, one in master branch before all changes, one in designers branch without programmes changes, one in programmes branch without designers changes. And now we must merge designers changes and programmes changes into master branch, but we cant.
So the question is - how to organise right this situations? Maybe we can setup perforce to checkout binary file in multiply branches at the same time, or something like this? Thanks...
There are a couple of different ways to think about this.
If you don't want work to continue/begin in one branch, until changes from another branch have been merged in to it, you can use Helix (Perforce) Protections, to give users read-only access to the branch.
This means they will be able to open files for edit, but won't be able to submit their changes.
More info about protections is here:
https://www.perforce.com/perforce/doc.current/manuals/p4sag/chapter.security.html
The protections would need to be changed, when you are ready for work on the other branches to start.
If you want a file to be automatically checked out on all branches, each time someone checks it out on any branch where it exists, you would currently have to script this.
You could do it using the broker and a workspace for every branch, that has a view that just includes the files you want to be checked out everywhere.
The files would then need to be checked out in these workspaces and locked, so that other users can't submit to these branches until the locks are removed.
This is not trivial and may have a performance impact.
You might also be able to do it using pre-command triggers, if your server version is new enough.
If you want to go in to more detail about any of the above, I recommend you contact Perforce Technical Support.
Hope this helps,
Jen.
We use JIRA in our organisation. I am unable to find the branch tag/commit-id against particular feature. Is there something I'm missing?
To understand a feature I want to understand all the changes that were made for this feature. How do I go about finding them?
Assuming your JIRA is connected to some kind of source code management (Bitbucket or Github). The branch / commit name must contain the JIRA issue key.
Jira: assign an existing git branch to an issue
Creating the branch though the UI is just a convenience. The important thing is that the name contains the JIRA key. If only one developer is working on the branch, it's fairly easy to just rename (delete + add) a branch with the appropriate name.
To find all branches / commits related to an issue, there's the Development Panel on the sidebar right.
The jira key in the git commit message we found needs to be in uppsercase, well case senstive depending on what you set in the integration.
I have the following situation of branches in a Perforce repository: There’s a mainline “trunk” and two release branches “1.0” and “1.1”. A branch “customer” with customer specific changes has been branched off the 1.0 branch. Now the customer wants to move to version 1.1. How can I merge the 1.1 branch into the customer branch? The customer specific changes should remain “on top” of 1.1.
Here’s a diagram for one affected file:
1.1 -(1)---(2)---(3)
/ \ \
/ \ \
trunk 100--(101)-(102)--103---104---105---106---107
\
\
1.0 ---1-----2--...
\
\
customer ---1-----2----*3*
The current version of the file I’m looking at is revision 3 on the customer branch.
If I choose to integrate branch “1.1” with target “customer” I would have expected that the common ancestor of both is found (revision 100 on mainline) and all revisions from there leading to the tip of the 1.1 branch are merged (the ones in parentheses).
Instead Perforce only offers to merge revisions 1 to 3 of the 1.1 branch, which fails because it misses the necessary changes that happened on mainline before.
How can I persuade Perforce to do this without having to look at each file manually and selecting the revisions to merge? Maybe the branching strategy is unsuitable? What else should I do?
When you try to integrate revision 3 from your 1.1 branch, Perforce will only tell you that it's integrating changes on that particular branch -- but revision 1 already contains trunk revisions 101 and 102. When merging, Perforce will identify trunk revision 100 as the common ancestor for conflict resolution.
It's been my experience that the integration you're trying to do should Just Work. Are you seeing changes missing in your integrated source (that can't be explained by improper conflict resolution), or are you just looking at the output of p4 interchanges?
I'd strongly suggest trying to merge the customer's changes into the trunk. It's going to continue to be a maintenance nightmare when a few months down the line the customer wants to upgrade to 2.0 + their custom changes.
If you don't want the customer changes reflected in your main project, take the time to restructure the code so that you can expose the customer's desired behavior with a build flag or build configuration file. Have both build configurations running in CI to ensure that future changes don't break the customer's build.
To make integrations easy, I would create a specific branches trunk_to_custer and 1.1_to_customer and then issue:
cd customer-workspace
p4 integ -b trunk_to_customer #change-number-at-which-1.1-was-branched
p4 resolve
perhaps an in-between submit here, and then
p4 integ -b 1.1_to_customer
p4 resolve
p4 submit
I would like to get an automated changelog from Trac, that will include references to tickets that made some important changes to the architecture/design of the code. My ideal scenario would look like this:
According to some ticket I make a change to SVN
I add some specific line to the ticket saying that this changeset created an important change to the code/wiki
I go to some dedicated Trac page and see a full list of such changes made with the project.
In other words, it's going to be a changelog, which is available for all project participants, and the entire team will be updated about the important changes with source code and wiki.
Can you suggest any Trac plugin for this? Or maybe Trac itself can do it?
ps. Would be excellent to have another "Plans Log", where everybody can post their plans on future changes. Again, inside tickets.
Have you tried the ChangeLogMacro on TrackHacks: http://trac-hacks.org/wiki/ChangeLogMacro
Sample:
[7280] by doki_pen on 12/18/09 20:27:15
Update body reference to output.
Since body isn't defined. Fixes #5538
[7191] by doki_pen on 11/26/09
02:18:32
watch user feature
fixes #3546
[7190] by doki_pen on 11/26/09
02:18:21
copy changes
trying to make things more intuitive
for users
Personally I'm looking for something a little more like the VirtualBox changelog which I can then put into a plain text file. So if anyone knows how to do this I'm interested!
www.virtualbox.org/wiki/Changelog
Sample:
VirtualBox 3.1.2 (released 2009-12-17)
This is a maintenance release. The following items were fixed and/or added:
VMM: fixed SMP stability regression
USB: fixed USB related host crashes on 64 bits Windows hosts (#5237)
Main: wrong default HWVirtExExclusive value for new VMs (bug #5664)
Main: DVD passthrough setting was lost (bug #5681)
VBoxManage: iSCSI disks do not support adding a comment (bug #4460)
VBoxManage: added missing --cpus and --memory options to OVF --import
VirtualBox 3.1.0 (released 2009-11-30)
This version is a major update. The following major new features were added:
* Teleportation (aka live migration); migrate a live VM session from one host to another (see the manual for more information)
* ...