I am working on a fabric file to make our code deployment process a little bit easier. Now I would like to have dependencies between certain tasks, similar to what is discussed in one here.
Let's simplify the problem and say I have two task: build and deploy. The build task should build our code and the deploy task will transfer it to a deployment server.
Now, deploy obviously depends on build, but build could also be a standalone task. So someone could just build the code with fab build or deploy the code with fab build deploy. But I also want people to use fab deploy for convenience, but then it should run build first. But build should only be executed once.
So if I include build into the deploy task and then do fab build deploy it will run build twice and then deploy.
I managed to do this with the runs_once decorator and execute function.
The build task is now decorated with runs_once and every task that depends on build, e.g. deploy, will do execute(build) at the beginning. This will execute the build task or silently fail if it was already executed (thanks to the decorator).
This is more like a workaround than a solution but it works in my case. Regardless, thanks to everyone for their input
Related
I'm new to CodeBuild and have built a CodeBuild project that builds a set of AMIs.
It takes a long time to run. In other build systems like circleci and concourse I've used features that allow build steps to run in separate docker containers in parallel and the build system waits for them all to finish and then proceeds to the next step.
Does CodeBuild support something like this? I don't see that it does...
If it doesn't, what is the best approach? Is this a use case for CodePipeline?
I could also pass in each ami as a parameter to the build and run n copies of the build simultaneously (trigger with a script that launches one build per ami).
Thanks for any thoughts!
Below is the existing answer in StackOverflow that might help you achieve the parallelism.
CodePipeline buildspec and multiple build actions
I have configured TeamCity with Git to get my ASP.NET MVC project.
My solution contains the web app and the corresponding unit tests:
MY_SOLUTION.sln:
- WebAppProject
- SomeCoreLibrary
- SomeCoreLibraryTests
- OtherProjects...
The steps that I have configured in TeamCity are the following:
Get external packages using NuGet
Build the solution and deploy it
Run Unit Tests
Run Automated Tests (using Selenium)
I want to run the unit tests after building but before deployment and stop deployment if the unit tests failed. Currently the deployment is done after the build using the following Command Line Parameters:
/p:VisualStudioVersion=11.0
/p:DeployOnBuild=true I want this to be done only after SomeCoreLibraryTests.dll unit tests have passed
/p:PublishProfile=MyWebDeploy
/P:AllowUntrustedCertificate=True
/P:UserName=username_here
/P:Password=password_here
Thanks,
Ionut
What I've done in similar cases is to use RoboCopy to just mirror the new website into the deployment path. Doesn't that work for you?
P.S.: if you do get this working, I'd suggest doing a performance improvement change in TeamCity (which would allow you to run the unit tests in parallel to the automated tests):
I assume you are employing a single build configuration for all those steps. If that is the case, what I would recommend instead is using Dependent Build configurations to separate the different concerns. You can see an example here in an open source project of mine:
http://teamcity.codebetter.com/viewLog.html?buildId=112432&buildTypeId=bt1075&tab=dependencies
Log in as Guest and expand the Testeroids :: Publish to NuGet tree node to visualize the build flow.
To achieve this, basically you pass around the result of your build step in the artifacts (e.g. you pass the resulting binaries from Compile into Unit Test). You gain several things by using dependent builds: several independent build steps can run in parallel on different agents, plus if one of your build steps fails because of external factors (e.g. let's say Publish failed because the network went down), you can trigger again the build and it will only rebuild the failed steps.
I am not familiar with the tools that you use. However, I would, in general, use a few build configurations for a project:
build configuration, triggered on change, containing these steps: get the latest source code and packages, build/compile and unit test. Then create an artifact for deployment task.
build configuration to deploy to a development server, triggered by successful completion of and using artifact (via dependency) from (1).
build configuration for long running (eg integration/functional) testing that is scheduled to run less frequently.
An advantage of (2) is that you can, if necessary, re-deploy a build/artifact without having to rebuild the artifact first. Also, if you have multiple agents, (2) and (3) can run independently of each other.
Furthermore, you can also tag build in (2) that have passed development checks and then use its artifact in another build configuration to deploy it to test server, etc.
Question: What is the best solution for executing a 'mvn deploy' such that the deploy part is only run after all unit tests succeed and no processing steps are duplicated?
I was hoping the simple answer was: Execute maven command 'x' (or use a flag) such that the deploy can be run without invoking the prior goals in the default lifecycle.
Sadly this does not appear to have a simple answer. I have included the details on the path I have followed so far below.
We have the following three requirements:
Execute the maven deploy goal to deploy all multi-module artifacts to a remote repository.
Only deploy if ALL unit tests across all projects pass.
Do not repeat any processing.
We started with simply "mvn clean deploy", however we noticed a couple issues:
the build would stop before completing all unit tests :: so we added the --fail-at-end flag
The deploy goal would execute against any modules that were successful.
This results in a "corrupted" state where the remote repository may only has a partial deployment (if there were modules with failures later in the build).
We looked at 3 different solutions:
Staging the artifacts prior to deploying :: this was determined to be too heavy for a fully automated process.
Use a profile to override the default lifecycle such that 'mvn deploy -Pci-deploy' would run without invoking any prior goals :: this worked and was fast, but is obviously an unconventional approach.
Simply running 'mvn clean package' and then only iff successful execute 'mvn deploy' :: this appears to work and seems to only take a minor hit when the goals are invoked (though some of them are smart enough not to reprocess an unchanged workspace)
I pose this question to the community with the background details I have provided to determine if there is a better approach or a strong opinion regarding (potentially) making one of the following requests:
A new deploy goal that can run separate and apart from all other lifecycle goals with the expectation that: all prior steps have already been run and that it will execute the deploy identically to "mvn deploy"
a flag in the deploy goal which would effectively disable the previous goals.
a little more out of the box and definitely against the current convention:
a flag that would tell maven to run the [unit] test goal for all modules prior to proceeding.
Notes:
We are using Jenkins, but for the purposes of this question the CI environment is not the complication.
I tried the 'mvn deploy:deploy' goal, but it had a number of unclear errors.
I have not considered integration tests as part of the requirements.
Update 8/20/2013
I tested the deferred deploy plugin and determined that the tool worked as expected, but took way to long.
For our code base:
mvn clean deploy: for all goals executed in 2:44
mvn clean install 'deferred-deploy-plugin': for all goals executed in 15 min
mvn clean package; mvn deploy -Pci-deploy a custom build profile that disables the earlier goals executed:
for all goals (including deploy): 4:30
deploy only: 1:45
mvn clean package; mvn deploy -Dmaven.test.skip=true on the same workspace executed:
for all goals (including deploy): 4:40
deploy only: 1:54
The clean package followed by deploy skipping the tests runs faster than the deferred deploy and accomplished our desire to delay the deploy until after the tests succeed.
There appears to be a minor time hit for when the deploy lifecycle executes and exits each of the preceding goals (process, compile, test, package, etc). However the only alternative is to hack a non-standard execution, which only saves 10 seconds.
There's a new answer now. Since version 2.8 of the maven deploy plugin there's a way to do this "natively". See the jira issue for details.
Basically you need to force at least v2.8 of the plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8</version>
</plugin>
and use the new parameter deployAtEnd. more info here. This setting usually goes along with installAtEnd of the maven-install-plugin
As an alternative, I also found this
http://code.google.com/p/maven-deferred-deploy-plugin/
A maven plugin that iterates through all projects in a reactor and
executes a deploy on each project individually. Can be used to produce
a near-atomic build for a reactor by deferring artifact deployment
until the install phase has completed.
Sounds alot like what you were asking for. I still think my other answer is easier to implement since you use jenkins, just check a checkbox
Two things.
Disabling all the previous phases i don't see it as an option. It is a basic feature of maven, you would be altering the standard lifecycle so i highly doubt anyone would implement something in a plugin to allow this
Since you said you use Jenkins, there is a setting in jenkins specifically for the case of deploying at the end to guarantee that the repo is not in a corrupt/intermediate state
In "Post-build actions"
Deploy artifacts to a Maven repository. In comparison with the
standard mvn deploy, this feature allows you to deploy artifacts after
the entire build is confirmed to be successful.
This prevents a typical problem in Maven, where some modules are deployed before a critical failure is discovered later down the road,
rendering the repository state inconsistent.
Note that regardless of this configuration, you can always manually come back to Jenkins and deploy any of the past artifacts to
any repository of your choice, after the fact.
To use this feature you shouldn't deactivate the automatic artifact archiving.
I have never used this so i can't confirm whether it works, I just know it's there for this particular use-case
I've got a build Travefy :: Build, Unit Test, Package that I run on every checkin. I have been running it manually to test it as well.
This is a build trigger for Travefy:: Deploy to Test Environment. It triggers every time Travefy :: Build, Unit Test, Package completes a build.
As you can see below, even after a successful build of Travefy :: Build, Unit Test, Package, the deploy is not triggered. I'm puzzled as to what is going on. Anyone have a clue?
It looks like Deploy has a Build as a dependency. In this case if you trigger Build, your Deploy won't be triggered.
But if you trigger Deploy first, then it first will trigger Build and will wait for it execution and after that will executed itself.
Also you have a Finish Build Triggered configured. So it could be those two doesn't fit to each other very good. Or you have some misconfiguration in your trigger. But I would recommend to leave trigger and configure everything through build chains -- it is much flexible and solid mechanism.
I have a TeamCity job that builds my project and runs all the unit tests, and another one that deploys the build to the production server.
Can I disable the "deploy" job so that it's impossible to deploy code if there's currently a failing test in the build project?
Shouldn't the deploy job already be dependent on the build one? Through Artifacts Dependency? You can set up the build trigger for the deploy job to be a successful build trigger on the build job so that the deploy happens when there is a successful build. Also, if a deploy job is triggered, it will take the last successful build. So if unit tests in the build job are failing, that build is not considered.
I wouldn't recommend snapshot dependency though, because it means when you deploy you try to trigger a new build, that is not the logical flow. Of course in the snapshot dependency you can say trigger only if a suitable build is not available ( or something like that ) but still snapshot dependency is not the way to go for this case.
Set up a Snapshot Dependency for Deploy on the most recetly finished Build and make sure the properties to say reject if failed [and make sure Build fails if tests fail in the General settings]