Background:
Our development team is looking to hand more control to the QA team with regards to deploying candidates to their environment.
The Process:
Once all Dev tests are complete, build quality is updated to "Ready for Deployment"
QA can kick off their "build" which takes the last version of the code, which was already built prior to step 1 and has been flagged as "Ready for Deployment, and pushes it to the QA environment.
The Question:
In MSBuild, how can we select the latest build of "Ready for Deployment" quality to target for deployment? Note that there may be subsequent check-ins or builds after the build that was flagged as "Ready for Deployment." If this is not possible in MSBuild are there other tools which will facilitate this process?
Final Note: We have the actual MSBuild deployment completed so this is out of scope for this question, we are only challenged with how to targeted the correct build.
our source code in TFS is branched into 2 separate sides with in a solution. One is DEV and the other is called MAIN. Once I have my changes working in DEV I check in my code. Then I merge the changes into the MAIN branch. The code located in the MAIN branch is used to deploy to QA and I can keep working on the DEV branch without interrupting the QA Build. Hope this helps.
Related
Context
We have a C# project, hosted in Azure devops.
We have a pretty standard workflow :
build + unit tests,
manual QA,
then mark the built artifacts as "validated by QA".
These artifacts are then made available to our deployment team.
Since our product is deployed on our clients' premises, the actual deployment will not be triggered from the azure pipeline.
Situation
So far, we work with a build job, and we communicate with the deployment team by sending a notification : "build 345 is validated, use that one for deployment".
The problem is : they basically have access to the list of all builds, including the ones which were built correctly, but where QA found a bug for example.
What I would like to have
Give the deployment team access to a section where only validated builds are published.
This could be :
using a release pipeline : let the result of the release pipeline be to offer the artifacts for download
but I did't find an action which just states "publish the artifacts"
in the build pipeline, keep the builds in a "not yet completed" state, and wait for a manual action of the QA team to flag them as "success" or "failure".
I don't see a way to add a manual step to a "Build" job (and I think this would be a bad setup for a build job anyway)
Question
What would be the prefered way to represent this workflow in azure devops ?
Then you could have a release pipeline with only these tasks:
1. Manual intervention Sends an e-mail to the QA-team telling them to do their thing with build x.y.z. When the build is approved for release, someone from the QA-team signs into Azure Devops and lets the release resume.
2. Notification E-mail or whatever notification you're using goes out to the deployment team, informing them about the newly approved build.
We have dozens of code repositories in Azure DevOps, and we're working on a major release strategy.
We have a stable development branch called develop, where code has been tested and peer-reviewed, with features approved by QA. All of our service repositories have a similar structure.
We want to "click a button" and branch from develop across all our repositories to a release candidate branch, that QA can regression test as a complete system... basically a "snapshot" of what we expect is ready for release. We would then build from this code base, release to our QA environment from the corresponding builds, and when certified, deploy to production, then smoke test and merge the release candidate branch into master, then master back into develop.
It doesn't seem like there's an easy way to manage multiple builds or releases in Azure DevOps though. Atlassian's Bamboo supported this concept of "meta builds" but I don't see a way to do this in Azure DevOps. I can't seem to even create a build that is not implicitly linked to a single repository.
How can I automate this and get this workflow working in Azure DevOps?
You can use a Build Task from the Marketplace that queue a new build: the first two found are Trigger Build Task and Build Chain.
You defined an overarching build that queues the single ones and does any additional work.
I am thinking to implement branching of the source code for release build which is currently happening from main trunk. So the way it will be structured is below
Release
UAT-sprint01
Source
Common
Web
UAT-sprint02
Source
Common
Web
I got the build definition that does the job and it deploys from main trunk. I am looking to update build definition so that it could pick up the latest one from release branch and does the build/deployment. It should also have the provision to pass the release branch version in case I want to deploy any particular one.
You sold move your deployment to a release management tool rather than a build tool.
You can use octopus deploy or release manager for visual Studio to deploy you software in a release pipeline.
http://nakedalm.com/blog/create-release-management-pipeline-professional-developers/
I was hoping for some guidance on the best way to promote a build through its environments.
We have 3 environments, DEV, STAGING, PROD.
The DEV Jenkins build is running in a continuous integration set-up, as code is checked in to subversion, Jenkins will run a new build (clean, compile, test, deploy).
The tricky bit is when it comes to STAGING and PROD.
The idea was to be able to manually promote a successful DEV build to STAGING.
STAGING build would check out the DEV's SVN Revision number, build, test, deploy to staging and finally create a branch in SVN.
Lastly the release manager could manually promote the STAGING build to PROD.
PROD build would check out the branch from the previous STAGING build, deploy to PROD and tag the branch as a release.
I have tried to use a combination of the Promotion Builds Plugin and the Paramterized Trigger Plugin but with no luck. The Subversion Revision number doesn't seem to get passed between DEV build to STAGING build.
Does anyone have any guidance on their process to promote a build through multiple environments?
Another approach is to make use of the Artifact storage Jenkins provides coupled with the Copy Artifact Plugin.
When a build is completed, you could instruct Jenkins to persist your application, either as a compressed zip/tar.gz or as an application bundle (jar/war)
Trigger a downstream job and use the Copy Artifact to retrieve the recorded artifact from the upstream job (or use parameterised builds)
Deploy/Unzip artifact as necessary - Build shell script/maven deploy?
Retest application using the same sources/binaries as was created in step 1
Repeat for PROD as necessary
This approach would allow you to fingerprint the artifacts, and thus Jenkins would link builds together in the UI, as well as allow more formal sign off.
In this scenario, why do you need to go back and label the branch in svn? We don't use svn, but w/ TFS, when Hudson/Jenkins gets the code, the changeset number it has retrieved is in the build log. So we know what code the build came from, and could get back to it at any time.
Then we promote the build from environment to environment using Hudson, the source control system doesn't need to know where the code is deployed.
If it's absolutely necessary to store the SVN Revision ID, then add a build step to your DEV job that copies it to a file. Something like this:
echo %SVN_REVISION%>revision.ini
or something like this:
echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini
Then artifact revision.ini. When doing a STAGING build, use the Copy Artifact plugin (as mentioned by a previous user) to retrieve the revision.ini file specific to the build and load it into a variable. Then use that variable in a command line call to "svn" to build the tag.
Describe the process you use to develop web applications at a not-so-high level, focusing on VC, bug tracking, QA, unit testing, deployment and anything else similar (minus the planning/client communication side of things).
I'm new in this area, so my rough example (read: haven't used this process) is no doubt abit off, so to speak - point out it's flaws so I can learn.
Eg.
Create project repository on local SVN server.
Create batch/shell scripts for DNS mappings.
Check out project, begin work on local working copy.
Develop features as branches.
Track bugs with Mantis (link commits to bugs through it's SVN integration (no idea if that exists)).
Document as you go.
Do QA on branch.
Merge to trunk when stable.
Unit Testing?
Commit to repository when feature is implemented and stable.
Copy releases to tags in repository. Eg. /project/tags/rel-123/
Use Phing to upload to staging server. (Could someone please clarify exactly what a staging server is used for beyond 'testing'?)
Use Phing to prep live site for update, set up DB/deploy, etc.
Create/checkout HEAD version ("main branch")
Develop code and sync with the main branch -at least- daily
After development is done, write and run unit tests
Go through code review and submit code/changes to the main branch
Let continuous builder run all unit tests and system/integration tests on main branch
When ready, cherry pick revisions and integrate them to the QA branch
Run system and integration tests, fix reported bugs, or rollback as necessary; this repeats steps 4-7
After QA signoff, integrate QA change to release branch
Run unit tests, system/integration tests on release branch
Deploy to production and run sanity tests.
A staging server is a copy of your production environment that is as up-to-date as possible. On my current project, we're able to keep each release independent from each other, so our "staging server" is our production server, just accessed from a different url.
Notes and discreprencies:
All of the steps have some variation depending on the size of your project. The larger your project, the better the benefit from cherry picking and environment separation. In smaller projects, these can just be time sinks and are often ignored or bypassed.
To clarify, there is a Development stack, QA stack, and Staging stack. Depending on your project size, QA might be staging, Production might be staging, or some combination thereof. The separation of the Dev and QA stacks is the most important one.
In the steps above, I'm assuming both code and relevant data is versioned or tracked. Having a release and build process that takes control data into account makes a release very, very easy.
In a small-medium sized project, there may or may not be a release branch; it depends on the frequency of code change. Also, depending on the frequency of code change and size of your project, you may integrate the full QA branch to the Release branch, or cherry pick specific revisions to integrate to the release branch.
FWIW, I've found "migration scripts" to be of little value. They're always a one-off script with little reuse and make rollbacks a pain in the ass. Its much easier, I would argue better, to have the application backwards-compatible. After a few releases (when a rollback is a laughable), data cleanup should be done, if necessary.
Very roughly:
Create repository in SVN
Checking local working copy to developer environment
Update/commit changes frequently
Deploy to stage from SVN trunk using custom deploy script
QA tests on stage, reports bugs in Mantis
Developers fix bugs, mark as resolved
Re-deploy to stage
QA tests bugs, closes if fixed
QA is finished, do regression testing
Deploy to production using custom deploy script
Do a little dance
We also create branches for future versions or features. These eventually get merged into the trunk.
We keep our db structures synchronized with a custom db comparison tool that is executed during the deploys.
Old post, but interesting question !
At my company now :
Create a new Github repo
Configure Jenkins
Clone locally
Start a branch
Develop and add tests (server, client and e2e)
Commit for every step, and fetch + rebase to keep the branch in sync
When ready, push the branch to the server : a pre-commit check lint and tests and block if not ok
Create a pull request for the branch
Here, jenkins automatically runs tests on the branch and flag it as "green" or "broken tests" directly in the pull request
Have at last 2 colleagues review the pull request and fix their findings (back to step 5)
When everything green and 2 colleagues have agreed, the last one merges the pull request
Delete the branch on server
When ready, push a new version
Latest version get immediately deployed on a testing platform
QA validate the corrections and features introduced (back to 5 if problem)
(TODO) deploy to a pre-prod with identical parameters than the production
Deploy to production
Go apologize to users for the bugs introduced ;) and report them in the issue manager
get feature requests and report them in the issue manager
restart cycle at step 2