I am trying to learn how YAML specs works in Bamboo. So far I achieved to deploy the plan following the official documentation. enter link description here
The documentation explains that you need to create a bitbucket repository, create bamboo.yml, set a new project in bamboo, enable a bamboo specs repository and finally you get your plan created and based in YAML specs.
My question is, can I create a plan.yml and deploy it from other bamboo plan?
For example, for JAVA specs, it is enough to checkout a repo with several *.java specs files and use maven and a pom file to deploy all the plans.
Can I do something similar with YAML specs? To have a folder in some SCM with several *.yml files and deploy them simultaneously. As a result, to have a lot of plans in bamboo deployed and based on the yml files.
yes and no, yaml can't be sent to the server as you can do with java specs. It needs to be committed to the repo first
you also need to have your different project created prior to committing the yaml specs and or have that repo granted access to each individual project or enabled the flag on the linked repo to allow access to all projects in the specs tab.
if this is not an issue,then yes there is no problem defining multiple plans in your bamboo specs yml file, even across multiple projects, as long as they are split up in separate yaml documents (with "---")
Related
I am trying to set different artifact paths configuration wise. e.g
In general settings of teamcity I am specifying following artifact paths:
testing\obj\Deploy-Dev\package
testing\obj\Deploy-Test\package
testing\obj\Deploy-Live\package
But when I am publishing a site using the following:
/M /P:Configuration=%env.Configuration% /P:DeployOnBuild=True/P:DeployTarget=MSDeployPublish /P:MsDeployServiceUrl=%env.TargetServer%/MsDeployAgentService /P:DeployiisAppPath=%env.IISPath% /P:MSDeployPublishMethod=RemoteAgent /P:CreatePackageOnPublish=True /P:Username=%env.username% /P:Password=%env.password%
In this step I am using only 1 configuration. I am assuming that by specifying these artifact paths. it will also transform the web configs according to specified configuration. But it is only transforming the one specified while actually packaging.
Any idea how to have web configs transformed in all packages as well.
I am not sure if I fully understand your question but here is what I think that you are asking. "How can I create a web package which has all the web.config transforms required so that I can publish the same package to multiple different environments?"
Unfortunately the way that packaging works is that the web.config is transformed using the web.config transform of the build configuration which is being built. Then the transformed web.config file makes it into the package. The transform files are not packaged.
I do realize that it's important to create a single package and publish that to different locations. We were not able to build the features into the box but I have created a NuGet package, PackageWeb, which can help in this case. I have a 5 minute video posted at http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx which you can take a look at. I am fairly certain that it will help in your scenario. FYI the code for package-web is open source at https://github.com/sayedihashimi/package-web. We do have some known issues. If you do end up using this please do let me know.
Try setting a environment variable for your teamcity artifact path.
testing\obj\%env.Configuration%\package
Troy Hunter -You're deploying it wrong! TeamCity, Subversion & Web Deploy part 5: Web Deploy with TeamCity
Artifact paths do not affect build\packaging process anyhow. They just provide ability to keep some files\folders available after build for further access.
If you want to produce 3 different packages, you will need to specify 3 corresponding build steps in your configuration and get rid of '%env.Configuration%'.
I am committing a bundle(say Test.jar) to the Apache Ace Repository using the HTTP API, http://<Ace Host>/repository/commit?customer=apache&name=shop&version=2. After this how can i provision this bundle to a target?
I am a bit puzzled by your question because the repository you mention contains metadata (in XML format) that describes the relationship between artifacts (bundles or other files), features and distributions. You should not commit bundles to it. Bundles go in the OBR, which has its own REST API if you programmatically want to upload them.
To provision a bundle to a target, using the Web UI, you:
Upload the bundle as a new artifact. It will be sent to the OBR and show up in the artifacts column.
Associate the artifact with a feature and the feature with a distribution.
Launch an new target and watch it show up in the UI (you might need to "retrieve" the current configuration for that to happen).
Associate the distribution with the target.
Commit everything.
I have a project that need to be deployed into multiple environments (prod, test, dev). The main differences mainly consist in configuration properties/files.
My idea was to use profiles and overlays to copy/configure the specialized output. But I'm stuck into if I have to generate multiple artifacts with specialized classifiers (ex: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") or should I create multiple projects, one project for every environment ?!
Should I use maven-assembly-plugin to generate multiple artifacts for every environment ?
Anyway, I'll need to generate all them at once so it seams that the profiles does not fit ... still puzzled :(
Any hints/examples/links will be more than welcomed.
As a side issue, I'm also wondering how to achieve this in a CI Hudson/Bamboo to generate and deploy these generated artifacts for all the environments, to their proper servers (ex: using SCP Hudson plugin) ?
I prefer to package configuration files separately from the application. This allows you to run the EXACT same application and supply the configuration at run time. It also allows you to generate configuration files after the fact for an environment you didn't know you would need at build time. e.g. CERT
I use the "assembly" tool to zip up each domain's config files into named files.
I would use the version element (like 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) and thus tags/branches at the VCS level in combination with profiles (for environments specific things like machines names, user name passwords, etc), to build the various artifacts.
We implemented a m2 plugin to build the final .properties using the following approach:
The common, environment-unaware settings are read from common.properties.
The specific, environment-aware settings are read from dev.properties, test.properties or production.properties, thus overriding default values if necessary.
The final .properties files is written to disk with the Properties instance after reading the files in given order.
Such .properties file is what gets bundled depending on the target environment.
We use profiles to achieve that, but we only have the default profile - which we call "development" profile, and has configuration files on it, and we have a "release" profile, where we don't include the configuration files (so they can be properly configured when the application is installed).
I would use profiles to do it, and I would append the profile in the artifact name if you need to deploy it. I think it is somewhat similar to what Pascal had suggested, only that you will be using profiles and not versions.
PS: Another reason why we have dev/ release profiles only, is that whenever we send something for UAT or PROD, it has been released, so if there is a bug we can track down what the state of the code was when the application was released - it is easier to tag it in SVN than trying to find its state from the commit history.
I had this exact scenario last summer.
I ended up using profiles for each higher environment with classifiers. Default profile was "do no harm" development build. I had a DEV, INT, UAT, QA, and PROD profile.
I ended up defining multiple jobs within Hudson to generate the region specific artifacts.
The one thing I would have done differently was to architect the projects a bit differently so that the region specific build was outside of the modularized main project. That was it would simply pull in the lastest artifacts for each specific build rather than rebuild the entire project for each region.
In fact, when I setup the jobs, the QA and PROD jobs were always setup to build off of a tag. Clearly this is something that you would tailor to your specific workplace rules on deployment.
Try using https://github.com/khmarbaise/multienv-maven-plugin to create one main WAR and one configuration JAR for each environment.
Bear with me, I'm migrating from Ant to Maven2: I think I've hit one of those little things that was easy in Ant, but not so in Maven...
How do I handle the difference between a local deployment vs. creating an archive/bundle for distribution to another machine?
Let's assume my project's output is an EAR plus some additional config files. A developer that is actively working on the project will need to deploy and re-deploy frequently to his local app-server (say JBoss), while an Integration Engineer that is building for QA/production will need only to create the final archive assembly (tar/gz).
In Ant we had two targets for this: "dev-deploy" and "bundle". Both do a complete build, but differ in the final step: "dev-deploy" copies the EAR and config files to the respective local folders, while "bundle" just puts the EAR & config files in a tar.gz assembly.
How do you do this in Maven?
I've seen that the assembly plugin can create either archives (tar, gz, etc.) or exploded directories (from the same assembly descriptor). I can invoke either assembly:assembly or assembly:directory, but for the latter, how do I copy the final output to the local JBoss deployment folders? From a related post it seems that ad-hoc copying of files is not really what Maven is about, so an antrun copy is probably the most appropriate?
Finally, since the type of assembly may differ depending on who invokes it, it doesn't seem wise to bind assembly to the build lifecycle, not so? But this means that a developer will always need to invoke 'mvn package' followed by 'mvn assembly:directory' to rebuild and test a change. Conversely, an Integration Engineer will always need to run 'mvn package' followed by 'mvn assembly:assembly' to create the distributable archive. I was hoping for a one-command solution for each, or should I just script it?
In Ant we had two targets for this: "dev-deploy" and "bundle". Both do a complete build, but differ in the final step: "dev-deploy" copies the EAR and config files to the respective local folders, while "bundle" just puts the EAR & config files in a tar.gz assembly.
Not sure what you mean by respective local folders about "dev-deploy" but this sounds like what mvn pacakge is doing and "bundle" indeed sounds like a maven assembly.
I've seen that the assembly plugin can create either archives (tar, gz, etc.) or exploded directories (from the same assembly descriptor). I can invoke either assembly:assembly or assembly:directory, but for the latter, how do I copy the final output to the local JBoss deployment folders? From a related post it seems that ad-hoc copying of files is not really what Maven is about, so an antrun copy is probably the most appropriate?
I guess that we are talking about the Integration Engineer's tasks here. As you didn't explain what the "bundle" contains exactly, what the target application server is (my understanding is that you are using JBoss for QA/production too but, again, this is a guess), if this bundle has to be deployed automatically, it's hard to imagine all solutions and/or alternatives to antrun. But indeed, to copy/move/unzip/whatever the assembly, the maven antrun plugin is a candidate.
Finally, since the type of assembly may differ depending on who invokes it, it doesn't seem wise to bind assembly to the build lifecycle, not so? But this means that a developer will always need to invoke 'mvn package' followed by 'mvn assembly:directory' to rebuild and test a change. Conversely, an Integration Engineer will always need to run 'mvn package' followed by 'mvn assembly:assembly' to create the distributable archive. I was hoping for a one-command solution for each, or should I just script it?
My understanding was that the Integration Engineer was building the bundle. Why would a developer need the bundle? This is confusing... Anyway, I don't really need the details to think of an answer. You could actually declare the maven assembly plugin into specific build profiles, one for development and one for integration, and bind either the single or the directory-single mojos to the project's build lifecycle in each profile. This would allow to use only one command and avoid any scripting (really, don't go this way).
I have a project build that needs to include files from another svn location during the build. I want to execute an svn get and then copy these files to the appropriate folder for the build. Researching this issue it seems I could use ant tasks but I wanted to find out what might be the best approach to take for this build.
You can use the maven-scm-plugin. According to the scm matrix both checkout and update are allowed.
Robert's answer is good, if the project is large though you'll be checking out a lot of content to get e single file.
If you want to get an individual file from SCM, the Maven SCM API allows you to interact directly with an SCM repository to invoke arbitrary goals. In this related answer I provide an example of a custom Mojo that commits a single file, if you implement that mojo and change the command from add to checkout you'll avoid having to checkout the entire project.