If I run mvn deploy does it build new artifacts or it just deploy the already existing artifacts in to the remote server? - maven-2

Note: This question has been originally posted by Lahiru Gunathilake as an answer to another question. I'm moving it here as a separated question for the sake of clarity.
When we are doing a release we just build in our local machine and do the QA and then we host it in to repository. If we run mvn deploy does it create new artifacts, this cause having different artifact in the repository and in binary distribution because we are creating the binary distribution from our local repository. But if someone get the source code and do the build they'll get a different one. But if mvn deploy doesn't build but only deploy it's fine.

As explained in Build Lifecycle Basics:
A Build Lifecycle is Made Up of Phases
Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle.
For example, the default lifecycle has the following build phases (for a complete list of the build phases, refer to the Lifecycle Reference):
validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify the package is valid and meets quality criteria
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
These build phases (plus the other build phases not shown here) are executed sequentially to complete the default lifecycle. Given the build phases above, this means that when the default lifecycle is used, Maven will first validate the project, then will try to compile the sources, run those against the tests, package the binaries (e.g. jar), run integration tests against that package, verify the package, install the verifed package to the local repository, then deploy the installed package in a specified environment.
To do all those, you only need to call the last build phase to be executed, in this case, deploy:
mvn deploy
That is because if you call a build phase, it will execute not only that build phase, but also every build phase prior to the called build phase.
So, the answer is yes, mvn deploy will execute install and build the project artifacts. But if you don't change anything, this will produce exactly the same artifact.

Related

Bamboo build plans vs deployment plans for custom environment configurations

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.

Specifying version number when deploying from Bamboo to generic Artifactory repository

I am testing out automatic deployment of build artifacts from Bamboo to Artifactory. I installed the Artifactory plugin in Bamboo, and then set up a test build plan. I added an "Artifactory Generic Deploy Task" since I'm not using Maven, Ivy, or Gradle.
My repository layout is:
group / product / version / filename.extension
It was pretty easy to specify where the artifact should go in the "Edit Published Artifacts" field in Bamboo:
myartifact=>com.example/someproduct/${bamboo.buildNumber}
This is fine for snapshot builds, but what if I want to make a release with a specific version number? What do I put in place of ${bamboo.buildNumber}? Or do I need to take an entirely different approach?
It's normally preferred to promote a satisfactory snapshot build to a released status than to run an independent release build.
Although Artifactory's release promotion support was not implemented for Bamboo's generic build type, starting with version 2.6.0 you can actually implement your own build promotion strategy within Artifactory as a custom User Plugin and invoke the procedure via a REST-API command.
So the procedure becomes pretty simple:
Write a release promotion strategy.
Add a Bamboo build step that executes the promotion via REST.
Build your snapshots until you're satisfied with the state.
Execute release step.
We also keep an example of a release promotion strategy plugin in github.

How to install a jar file from target to a specific location using maven?

Currently I have a simple maven project that is building a jar file and putting it inside target/some-1.0.jar when i run mvn install.
I want to copy this file to another location when I run mvn deploy.
Currently the location is on the same machine, but it would also be great if the solution could be applied for multiple targets, some of them being on other machines (scp deployment).
What is the easiest solution to do this? I would be nice, if you could include an example too.
Details: I have few jira plugins that are compiled as jar files and I just want to be able to run a single maven command that would copy the files to the server and eventually restart the server.
mvn deploy is intended for deployment to a remote Maven repository. mvn install is used for copying to the local Maven repo (so actually, the jar is also ending up in $HOME/.m2/repository, as well as target).
I'm not sure what you're intending to do, but I suggest you look at deploying something like http://www.sonatype.org/nexus/ if you want Maven artifacts to be available to multiple machines. This will integrate nicely with the rest of Maven.
Edit: based on your updated question, it's probably best to investigate the Wagon ssh plugin, or see if there's an Ant plugin. A suitable phase would be pre-integration-test: install and deploy should be run after you've run your integration tests to check the artefact works as expected. Use profiles to distinguish the local vs. remote cases.

Build and deploy specific revision number with TeamCity

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.

What is the difference between "mvn deploy" to a local repo and "mvn install"?

My team uses an internal team maven repo that is shared from a development server using Apache. We also run the Continuum CI server on the same machine. Maven builds in Continuum are run with the "install" goal, which copies the final artifact directly into the shared directory.
The question is, what is the difference between adding files to the shared repo using mvn install and using the deploy goal (mvn-deploy plugin)?
It seems to me that using mvn deploy creates additional configuration hassles, but I have read somewhere that installing files into a shared repo is a bad idea for some reason related to the internal workings of maven.
update: I get the functional differences between deploy and install; I am actually more interested in the low level details in terms of what files are created in the maven repo.
Ken, good question. I should be more explicit in the The Definitive Guide about the difference. "install" and "deploy" serve two different purposes in a build. "install" refers to the process of installing an artifact in your local repository. "deploy" refers to the process of deploying an artifact to a remote repository.
Example:
When I run a large multi-module project on a my machine, I'm going to usually run "mvn install". This is going to install all of the generated binary software artifacts (usually JARs) in my local repository. Then when I build individual modules in the build, Maven is going to retrieve the dependencies from the local repository.
When it comes time to deploy snapshots or releases, I'm going to run "mvn deploy". Running this is going to attempt to deploy the files to a remote repository or server. Usually I'm going to be deploying to a repository manager such as Nexus
It is true that running "deploy" is going to require some extra configuration, you are going to have to supply a distributionManagement section in your POM.
From the Maven docs, sounds like it's just a difference in which repository you install the package into:
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
Maybe there is some confusion in that "install" to the CI server installs it to it's local repository, which then you as a user are sharing?
"matt b" has it right, but to be specific, the "install" goal copies your built target to the local repository on your file system; useful for small changes across projects not currently meant for the full group.
The "deploy" goal uploads it to your shared repository for when your work is finished, and then can be shared by other people who require it for their project.
In your case, it seems that "install" is used to make the management of the deployment easier since CI's local repo is the shared repo. If CI was on another box, it would have to use the "deploy" goal.