We have two branches for our solution, a dev and a main branch. We use the built in NuGet feed in TeamCity which is consumed by Octopus Deploy. The problem we have is we have one feed but two build tasks, one that builds the dev branch and publishes the artifacts and one that builds the main branch to publish the artifacts. We need a way to distinguish these packages, we are using the OctoPack plugin to build the packages.
What we would like is to end up with an artifact named: package-dev.1.0.0.0.nupkg
Is there a way using TeamCity to rename an artifact in this sense to append -dev before the version? Happy to append to the front, as long as Octopus Deploy picks up the latest version.
The way I tackled this issue is by using unique version numbers across multiple builds with Auto Incrementer as a team city plugin.
This will ensure that each build that uses the autoincrementer has its own unique build number but this is where you just have to ensure your team is communicating well about which version is in which environment.
So if the autoinc is at 50 it should be something like :
-> Dev branch build outputs package.1.0.0.50 , then
-> Main Branch outputs package 1.0.0.51
In octopus it's the same project or entirely different project!
Related
My Source code: 2 different branches from same repository. Both have 80% same code. Packages also same. But 20% classes are different in both branches. Its because of different features being developed in these branches.
My Intellij version is 2018.2.7 Community Edition
I cloned the repository in 2 different folders.
consider first one: C:\SourceCode\myRepo and move to branch1 from master
consider second one: C:\SourceCode\SecondCopy\myRepo and move to branch2 from master
Now I create 2 different projects in IntelliJ. One from C:\SourceCode\myRepo, Second from C:\SourceCode\SecondCopy\myRepo.
I build first project using git bash for windows using simple 'mvn clean install' command. (outside Intellij). Open Intellij. Run the application on Jetty. It goes good.
I have the second IntelliJ Project open as well in new Window. Now I build this second project in git bash using 'mvn clean install'(again outside Intellij). But as soon as I do that, the first project starts showing exceptions in code for the java classes which are not present in second project.
Even the application which was Already running using 'Run configuration of Intellij' in Jetty in First project, starts throwing class not found errors.
How can I resolve it and work on 2 projects having slightly different code but 80% same code, same packages etc. parallelly? What am I missing here? My intention is not to run Jetty parallelly. But to be able to compile these 2 projects independently and be able to Run Jetty in any one project anytime without interfering with other project.
These projects are big projects and hence, I want to initiate build and run for one project. Till the time its up and running, I want to be able to work on the other one parallelly in a way that, this work after compiling/auto building in this project doesn't impact the other one where I just started the application.
It is killing my productivity. Please help!
Use different Maven coordinates for the projects.
Someone told me that... Its happening because I am using maven and after building, maven keeps the project libraries that it builds in local repository. So both the projects after building are trying to keep the jars in the same folder from where Jetty is reading as well. Hence there is interference.
I have not tried. but If I keep 2 separate local repositories for both the projects, it should solve, but with this all the dependencies will also be unnecessarily duplicated. So the solution is as mentioned by #Andrey is that I keep the maven coordinates separate for both the projects, so that 2 separate jars are created for both. Thanks Andrey. I wont necessarily change maven coordinates for the all modules but for one where there is difference of code in both the projects. Hope this answer helps someone.
I have a TeamCity system running with various Debug and Release build configurations backed by Templates which match the Debug and Release configurations as follows
Branch Build Dev Template
Branch 1 Dev Build
Branch 2 Dev Build
Branch Release Build Template
Branch 1 Release Build
Branch 2 Release Build
I am considering separating the Dev and Release configurations onto two distinct servers to ensure that the Release configurations have a higher level of governance than the Dev configurations while allowing the Dev team to 'play' with the Dev build configurations.
I am not worried about the history on the Dev builds but I want to preserve the history on the Release builds. Therefore I want to copy the Dev build configurations out of the server and import them into a new server specifically for the Dev team.The server configurations are backed by a Git repo so I have a copy I can work from
Can anyone provide guidance on how to do this please?
I just found this SO question which pointed me in the direction of Projects Import which looks like a suitable approach for what I am trying to do.
However I want to move certain configurations from a project, not the entire project. If I can find anything further I will post the solution here.
I'm evaluating Bamboo to replace our Jenkins setup and have a couple questions. I have a .NET solution that generates two artifacts: a packaged website and an MSI. I have three environments I deploy to: test, stage, production. Our Jenkins server in turn has three jobs--one for each environment. Each job builds the solution, copies in configuration files for the environment it will be deployed to and then deploys the artifacts. Reading the documentation and other stuff (https://answers.atlassian.com/questions/19562/plans-stages-jobs-best-practices), I'm getting mixed signals about how deployment should work with Bamboo. It seems to me like deployment plans expect artifacts to exist and then deploy them. But, build plans include deployment steps as well. How is all of this supposed to interact together?
The reason I'm confused is because I have environment specific configuration files that get packaged during a build. Any direction on how this should work?
I posted the question to the Atlassian board as well and got an answer I think I like the best:
Jason Monsorno · 762 karma · Aug 30 '13 at 04:38 PM
Deployment projects in Bamboo seem to be dependant on the existance of
an artifact, the catch is you don't necessary need to use that
artifact so you could use an empty artifact and do completely
independent steps. Deployment projects are still fairly new to Bamboo
and your structure may favor the "normal" workflow so each environment
would be a separate manual stage.
The Deployment project do have a separate workflow and versioning. To
use Deployment projects in your scenario, I'd suggest making the
artifact the entire checkout then each Deployment environment can
build a copy of the artifact. The space-saving/less-time-efficient
option would be to just save the current revision in a file as the
artifact and use that to check it out and build in each Deployment
environment.
I'm just getting to grips with TeamCity and MSDeploy and have deployment to a dev environment triggered by SVN commit working nicely. The question I have is in terms of releasing to a test environment; I want to do this on demand and based on a specific revision number. What's the best way to configure a TeamCity build based on a user-defined revision?
You can use Run Custom Build Dialog in the TeamCity, and customize there Changes to include parameter, where you need to specify actually SVN revision to build.
Take a look on Pin functionality in TeamCity. You can pin a certain build and then deploy latest pinned build.
So you have a 'Create development build' task in TeamCity which deploys to dev environment and exposes artefacts. You can create another task in TeamCity that will use artefacts from latest pinned build in 'Create development build' task and deploy to your testing environment.
You can create yet another task that deploys to production latest pinned 'test' build. Rollback can be achieved by simply unpinning last pinned build.
You also have a history of deployed build.
I'm very new to Maven, and have a question about building multiple Maven projects.
We have two Maven projects, Project A and Project B.
Project A depends on an artefact generated by Project B.
When changes to project A or B are checked into SVN, our local Hudson server builds the modified project (and any dependent projects) and uploads the artefacts into our local Nexus repository.
Now, consider two developers.
Developer 1 hacks away at project A only, and when Developer 1 builds project A locally, Maven goes and gets the latest project B snapshot artefact from our Nexus server.
Developer 2 hacks on both project A and project B simultaneously. When Developer 2 builds project A locally, we want maven to build project B with any local changes and use the resulting artefact to build project A. How do we set up Maven to build using the local version of project B instead of getting the artefact from Nexus? Is this a standard usage pattern for Maven?
How do we set up Maven to build using the local version of project B instead of getting the artefact from Nexus?
You can setup an updatePolicy for the snapshots artifacts per repository. Actually, Maven checks for SNAPSHOT updates only once a day by default. So if you build a version of B locally, you should be able to use it to build A for some time, even if a new SNAPSHOT is deployed to your Nexus. If this doesn't suit your needs, you can change this policy. You could also build offline (using the -o option).
PS: AFAIK, automatic updates will be disabled by default in Maven 3.x, you will have to explicitly ask for updates (with the -U option).