We have a self-hosted GitLab FOSS instance. This version does not include any epics/stories and there is build-in way to create hierarchy between issues.
We are migrating a project from JIRA. The team that worked on this project where using epics/stories and sub-tasks. Are there any strategies to handle epics/stories in GitLab FOSS. I mean I know we would have to use labels and/or milestores, but has anyone ran into this situation.
Also, I know GitLab Ultimate has epics, but it is too expensive.
Epic in GitLab are indeed part of the "Portfolio Management" feature (issue 3254) of the GitLab Ultimate edition.
The only free alternative would be to have "sub-issues", which are being discussed in issue 4588, and illustrate how you would need to use labels.
For instance:
All sub-issues must use the same prefix for their title, preferably a meaningful shortened version of the main issue's title if it's too long.
This is a visual helper to quickly identify sub-issues and their main issue.
Each sub-issue must have proper labels:
the ~sub-issue label
the same type label as the main issue
the same release scoping label as the main issue
the same priority label and severity label as the main issue
the relevant specialization label to that particular sub-issue
This is still being implemented, with topics like "Provide first class support for Issue Task Lists and Tasks" (issue 2036).
Update March 2022 for GitLab 14.9 (Ultimate edition only)
Link an epic to another epic
GitLab now supports linking epics using “related”, “blocking,” or “blocked” relationships.
This feature enables teams to better track and manage epic dependencies across GitLab groups.
Effective dependency management is a key component of reducing variability and increasing predictability in value delivery.
Related
Given that action's versions derive from their repo's tags.
Can one change an already published version by moving the tag to another commit?
If so, it's a serious security problem.. but I can't find any source to reassure me.
Anyway, it is always possible to use commit id instead of version:)
Yes, that's possible. When a tag is moved to point to a different commit, the corresponding release becomes a draft and it disappears from the Marketplace, but it can be published again.
Notice that an action doesn't need to be published on the marketplace to be used anyway.
Moving tags is actually the official recommendation for major versions and it has been debated; that discussion mentions that versioning will improve when moving to using the GitHub Package Registry for Actions, but that hasn't happened yet and the GitHub roadmap doesn't mention it, as far as I can tell.
How to transfer the repository or a whole set of repositories from one gitlab group to another subgroup. For example companyname.gitlab.com/team one/. To gitlab.com/team_first/phase1/
The repositories/projects themselves still need to be exported by API, one by one.
But the new "Group Import/Export " feature from GitLab 13.0 (May 2020) can be a welcome addition.
Export and Import Groups in the UI
Previously, users could only migrate groups by using the Export/Import API to create an Export file, then using the API a second time to upload the file to the target instance.
As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI.
We plan to introduce similar Import functionality to the UI within the next few weeks.
See documentation, issue and Epic.
See GitLab 14.2 (August 2021)
Group Migration achieves parity with group import/export
The new GitLab Migration feature can now migrate an entire group with all its subgroups and related data. The data migrated includes everything contained in group exports, making this a much easier way to migrate entire groups.
The pre-existing group import/export is a two-step process that requires exporting a file and then importing it into another GitLab instance.
Now, users can initiate a group migration with a single click. Migration also includes all the subgroups and their data, which previously required separate export and import processes for each subgroup.
See Documentation and Epic.
See GitLab 15.6 (November 2022)
Associate MRs to issues when migrating groups with projects
When migrating groups using GitLab Migration, GitLab now preserves associations of imported merge requests to issues.
This populates the Related merge requests section
on the issue details page.
See Documentation and Issue.
I've read about GitLab's issue board feature (see links below), but it's not there on my instance. Under the 'Issues' page of a project, all I see are 'Issues,' 'Labels' and 'Milestones' -- nothing about Issue Boards. Why is this? Do source installations not have this feature?
My GitLab setup:
Community Edition
Created from source
Version 8.10
https://about.gitlab.com/solutions/issueboard/
https://www.youtube.com/watch?v=UWsJ8tkHAa8
Issue boards were introduced in Gitlab 8.11. Time to upgrade!
Notes:
Introduced in GitLab 8.11.
The Backlog column was replaced by the Add issues button in GitLab 8.17.
Note: with GitLab 13.5 (October 2020), you have pre-populated issue boards:
Automatically add To Do and Doing lists on new boards
In most cases, teams will be best served by keeping their workflows as simple as possible.
To encourage this and make the first experience with a board more efficient and approachable, creating a new board will now automatically pre-populate To Do and Doing lists so you can get straight to managing issues.
See Documentation and Issue.
We have currently released our code to Production, and as a result have cut and branched to ensure we can support our current release, whilst still supporting hot-fixes without breaking the current release from any on-going development.
Here is our current structure:
Project-
/Development
/RC1
Until recently using Octopus we have had the following process:
Dev->Staging/Dev Test->UAT
Which works fine as we didn't have an actual release.
My question is how can Octopus support our new way of working?
Do we create a new/clone project in Octopus named RC1 and have CI from our RC1 branch into that? Then add/remove as appropriate as this RC's are no longer required?
Or is there another method that we've clearly missed out on?
It seems that most organisations that are striving for continuous something end up with a CI server and continuous deployment up to some manual sign off environment and then require continuous delivery to production. This generally leads to a branching strategy in order to isolate the release candidate to allow hot fixing.
I think a question like this raises more points for discussion, before trying to provide a one size fits all answer IMHO.
The kind of things that spring to mind are:
Do you have "source code" dependencies or binary ones for any shared components.
What level of integration / automated regression testing do you have.
Is your deployment orchestrated by TFS, or driven by a user in Octopus.
Is there a database as part of the application that needs consideration.
How is your application version numbering controlled.
What is your release cycle.
In the past where I've encountered this scenario, I would look towards a code promotion branching strategy which provides you with one branch to maintain in production - This has worked well where continuous deployment to production is not an option. You can find more branching strategies discussed on the ALM Rangers page on CodePlex
Developers / Testers can continually push code / features / bug fixes through staging / uat. At the point of release the Dev branch is merged to Release branch, which causes a release build and creates a nuget package. This should still be released to Octopus in exactly the same way, only it's a brand new release and not a promotion of a previous release. This would need to ensure that there is no clash on version numbering and so a strategy might be to have a difference in the major number - This would depend on your current setup. This does however, take an opinionated view that the deployment is orchestrated by the build server rather than Octopus Deploy. Primarily TeamCity / TFS calls out to the Ocotpus API, rather than a user choosing the build number in Octopus (we have been known to make mistakes)
ocoto.exe create-release --version GENERATED_BY_BUILD_SERVER
To me, the biggest question I ask clients is "What's the constraint that means you can't continuously deploy to production". Address that constraint (see theory of constraints) and you remove the need to work round an issue that needn't be there in the first place (not always that straight forward I know)
I would strongly advise that you don't clone projects in Octopus for different environments as it's counter intuitive. At the end of the day you're just telling Octopus to go and get this nuget package version for this app, and deploy it to this environment please. If you want to get the package from a different NuGet feed for release, then you could always make use of the custom binding on the NuGet field in Octopus and drive that by a scoped variable depending on the environment you're deploying to.
Step 1 - Setup two feeds
Step 2 - Scope some variables for those feeds
Step 3 - Consume the feed using a custom expression
I hope this helps
This is unfortunately something Octopus doesn't directly have - true support for branching (yet). It's on their roadmap for 3.1 under better branching support. They have been talking about this problem for some time now.
One idea that you mentioned would be to clone your project for each branch. You can do this under the "Settings" tab (on the right-hand side) in your project that you want to clone. This will allow you to duplicate your project and simply rename it to one of your branches - so one PreRelease or Release Candidate project and other is your mainline Dev (I would keep the same name of the project). I'm assuming you have everything in the same project group.
Alternatively you could just change your NuSpec files in your projects in different branches so that you could clearly see what's being deployed at the overview project page or on the dashboard. So for your RC branch, you could just add the suffix -release within the NuSpec in your RC branch which is legal (rules on Semantic Versioning talk about prereleases at rule #9). This way, you can use the same project but have different packages to deploy. If your targeted servers are the same, then this may be the "lighter" or simpler approach compared to cloning.
I blogged about how we do this here:
http://www.alexjamesbrown.com/blog/development/working-branch-deployments-tfs-octopus/
It's a bit of a hack, but in summary:
Create branch in TFS Create branch specific build definition
Create branch specific drop location for Octopack
Create branch specific Octopus Deployment Project (by cloning your ‘main’ deployment
Edit the newly cloned deployment, re-point the nuget feed location to your
branch specific output location, created in step 3
I'm using Visual Studio Online for my TFS needs, and I have a pretty big solution which contains several web projects.
How can I set up automatic deployment of a specific project in the solution to a specific website on Azure?
The default workflow used to deploy in VSO does not seem to handle this scenario.
The "first" web project found within the solution is chosen for deployment according to this discussion. Note that the discussion relates to git on VSO but it seems to hold true for builds using the VSO CI workflow.
According to the discussion changing the project names to influence the ordering should/might work but results seem mixed.
We chose to add a second solution only containing the web-project to deploy, its dependencies and tests. This will not work if there are dependencies on other web-projects.
Also take not of this article on a configuration-based approach, a question that this one might be a duplicate of or a question concerning actual deployment of multiple projects into one site.