Simple situation, our Gitlab (Premium) group level structure looks like this (simplified):
Projects <- GitLab group
Customer project A ("PA") <- GitLab sub-group
App 1 related to project A only <- GitLab project
Library 1 related to project A only <- GitLab project
Customer project B ("PB") <- GitLab sub-group
App 2 related to project B only <- Gitlab project
App 3 related to project B only <- Gitlab project
Libs <- GitLab group
Lib 2 <- Gitlab project
Some generic libs <- GitLab projects
Apps <- GitLab group
App 4 <- GitLab project
Some generic Apps <- GitLab projects
The reason for choosing that layout is issue management. To have Epics, groups are required -> Customer project A and B. For issues and code, projects are required. To see all epics & issues in one issue board and one sprint/iteration, the easiest solution is to have one top-level project group with their dependent groups/projects underneath.
Generic libs and Applications have their own groups and their own lifecycles.
So far so good.
Now, it happens that PA (Customer project A) and PB (Customer project B) both depend on the same library, say Lib 2 and on the same application App 4 by coincidence.
What is the easiest solution to show the issues of Lib 2 and App 4 in the issue boards of Projects?
I was thinking of forking Lib 2 and App 4 into PA and PB to keep their relationship to its "base" project under Apps. But forking does not preserve issues and other settings, so that might not be the way to go.
What are your proposals? This must have happened a couple of times in the wild already...
PS: assume both projects are currently under active development. Releases of App 4 and Lib 2 are done in their "base" groups and dependency management on code level takes place via a package manager. This question is primarily about issue tracking (I guess)...
Thank you very much for any ideas!
Jan
Related
I have an asp.net web forms application. To implement Continuous integration/deployment process:
TFS
Dev branch
Master branch
Azure: App service
Dev Slot
Staging Slot
Prod
The lifecycle is :
The developer add some features and commit it to Dev branch ==> the commit will be automatically deployed to Dev slot
The requestor or the client see, test and validate modifications
If it is Ok ==> the developer merge his changeset to master branch
when the changeset were merged with success, it will be ==>
deployed to Staging slot
Test some important Url in staging slot
If it is OK ==> Swap Staging and Production slots
So at the end, we will have the versions of the application:
Version N+1 in the dev slot
Version N-1 in the staging slot
Version N in the production
This process works fine. Because of the csproj file, in some it didn't
Example :
A Developer add a subsite A and B
site B is validated by the client but site A did not
when the site B's changeset were merged to the master branch, the csproj file will contains A and B pages references
So we will have a compilation error in master, because site A's pages are mentionned in the csproj but it doesn't exist in this master branch!
So I need to know how can I fix this issue ?
Thanks,
You have a continuously integrated dev branch. When it comes to deploying, you find yourself asking the question, "How do I deliver a subset of what's presently in the branch?" At this point, you're trying to essentially un-merge. You don't ever want to "unmerge".
Instead, consider adopting a feature toggle pattern. This is a developer-centric activity, not a branching/merging activity. Your developers wrap any new feature behind a toggle that can be conditionally enabled or disabled. If Site B is approved for deployment and Site A isn't, that's fine -- deploy with Site A's feature toggle disabled. It's still in the code, but there's no way for your end-users to access it.
Another possibility is to adopt a microservice architecture where there are fewer hard dependencies. Instead, your application is comprised of many, smaller, independently versioned and deployed services. This will probably end up involving feature toggles too, of course.
The above two thoughts are coming from a place of modern application design. To go back to an older way of thinking: If you need to "unmerge", it means you're merging too early. You may need to maintain multiple development branches and QA features independently, only merging them together once the changes have been approved. This, of course, requires a longer QA cycle because you'll have to QA both features a second time, after they are merged.
The company I currently work for has a solution with 3 projects.
_Common... which was originally a Web project, but then changed to a Class Library.
Website1... Which is a website
Website2... Completely different website.
In Azure, we have a Deployment configuration so whenever our BitBucket Repo gets a checkin, it should build and deploy the solution.
Unfortunately, it seems like _Common is getting built as the target project. Which is breaking Azure.
ALSO Unfortunately, we have Two DIFFERENT Products (Website1 and Website2) which are in Two Different Azure Apps. They are both looking at the same BitBucket Repo, and both building whenever a checkin happens... but both are building _Common.
Can I have our "Website1" Azure App build the solution with Website1 as the startup project, and have our "Website2" Azure App build the solution with "Website2" As the startup project?
This obviously won't work to set the default project in Github, since we still need two different builds with two different startup projects.
You certanly can!
Go to your "Website1" Web App and go to Settings > Application Settings.
If you are using .Net Framework 4.5 or lower
Add a setting called Project, which value points to the CSPROJ file you want to build, using the full path from the repository root folder.
If you are using ASP.NET Core 1.0 / ASP.NET 5
Add a setting called Project, which value points to the folder that contains the project.json file of the project you want to deploy, do not include the filename in the path.
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 have a Visual Studio 2012 solution containing a Windows service project and a web application project.
I want Team City (version 8.0.3) to create two zip files (one for the service and one for the web app) that I will deploy manually.
Should I create a build step to build the entire solution, followed by a build step to publish the Windows service and a build step to publish the web site (via publish profiles). Then use Artifact paths in General Settings to zip up these two published folders?
Or should I have just one build step to build the solution and then use the Artifact paths to create the two zip files?
Or is there a better way than either of the above?
You have to ask yourself if these two projects are linked and in which manner they should be built together.
My feeling is : if your projects are in the same solution, they are linked in some ways and have to be built together.
Then, you should build your solution (sln) and not projects (*proj).
Application organization
Generally, your build server should not redefine -too much- the way your applications are organized. You should always use your plateform application descriptor to build your applications.
In case of .NET and Visual Studio, the application descriptor is your solution (sln). It defines the needs and how your application have to be built.
If your project have to be built separately, they should be in differents solution unless you prefer to create specific solution configuration (in addition to Release & Debug).
Anyway, the solution is still the build entry point.
TeamCity
Speaking about TeamCity, different and standalone applications should be in separate build configurations.
The pure build (code compilation) should be in one build step and you should not use too much code compilation runners in one build configuration.
Your build configurations should reflect your applications farm logic.
If you need to link them in some ways which are related to packaging for example, you can link your build configurations through snapshot or artifact dependency.
I am trying to use TFS Integration Platform to migrate my project A on server 1 to project A on server 2. I have branched code from project B on server 1 to project A on server 1 but I am not moving project B to server 2. Is there any way that I can use a default action for all conflicts to resolve by adding instead of branching on server 2 during the migration? If not, is there anything else I can do to get the code over from initial checkin without moving project B to server 2?
Thanks in advance!
It may be easier to move project A and project B, then do a tf destroy of project B. This should create a new baseline for those branched files.
Try it first, though, in a test environment.
I am assuming they are in the same project collection, in which case no - you will need to move all of A.