I am trying to follow GitLab flow with staging and production environments. I also want semantic-release plugin for both environments (with this I also need a branch for every environment so semantic-release could work, right?)
I have successfully made semantic-release working for staging branch, it creates vX.X.X-rc.x as expected and it also generates changelog. Great!
But how should I properly work with those branches? I think I understand how would I do that with only master branch and two environments, but I couldn't find any info about doing this with separate branches.
I create feature branch, finish feature, merge to master. Now what? Should I have deployment job, which on every merge to master automatically merges master to staging, runs semantic-release and then deploys it? And then have manual deployment which automatically merges staging to production, runs semantic-release and then deploys production?
And second think: how would I deal with forced commit message conventions? If I am merging feature to master, there is commit message feat(x): something something. But what should be in those automatic master to staging and staging to production merges?
Related
I am planning to experiment building a pipeline using Azure DevOps. One thing that I noticed early on is, after azure-pipelines.yml created, I have to commit this first before being able to run it. But I want to experiment on it which revolves around trial and error. Doing multiple commit just to test things out are not feasible.
In Jenkins I can just define my steps and try to run it without committing the file.
Is this also possible to do in Azure DevOps?
But I want to experiment on it which revolves around trial and error. Doing multiple commit just to test things out are not feasible.
Yes it is - you just use a different code branch. That will allow you the freedom to make as many changes as you need, while putting the pipeline together and trying it out, without committing to the master branch.
Then when you're happy with the way the pipeline is running, you can merge your branch into the master branch which the pipeline normally uses.
You cannot run YAML pipelines without committing them, but you can create classic pipelines and run them without committing anything pipeline-related to the repository (except for the source code you want to build). Classic pipelines can later be turned (or copy-pasted, to be exact) into yaml pipelines with view YAML -option.
https://learn.microsoft.com/en-us/azure/devops/pipelines/get-started/pipelines-get-started?view=azure-devops#define-pipelines-using-the-classic-interface
If you're on your own branch, or in a repository without any other developers making changes then you can
Make a change
use git commit --amend to overwrite your previous commit with the new file
use git push --force-with-lease to push that up to Azure DevOps
That will hide your commit history while experimenting
I have a .Net project that uses the Azure DevOps pipelines. The setup is that I have a build pipeline that creates an artifact. The artifact then automatically gets published through the release pipeline. This is working perfectly.
The problem is after I turned on the policy Build Validation, pull requests now triggers the build pipeline which then triggers the release pipeline. So every pull requests gets published. The build step is correct, but the release should not happen. The pre-deployment trigger "Pull request deployment" is disabled.
What I did to try to solve this is that I added a condition to the build step where the artifact gets created. So pull requests does not create artifacts, while merges does. This also works as intended. However, the release pipe still gets triggered, but this time without an artifact (which fails the pipe).
TLDR:
Release pipe triggers on pull requests, settings for this behavior is off. WTD?
My CI/CD settings:
Your release triggers on any of your builds and branches (PR also has a branch). You have to add the branch filter: Continuous deployment triggers. Restrict your filter with the master branch or any other. Also, you can define 2 build definitions:
A pipeline to validate your pull requests without linked releases.
CI pipeline that triggers a release.
Additionally, I think, this is a bug. Because the PR trigger is not enabled. Let's check dev community comments: https://developercommunity.visualstudio.com/content/problem/1292039/release-pipelines-ignore-pull-request-settings.html
What we have here is that we've set up build pipelines tied to YAML files stored in the repository, together with source code. And release pipelines have their Source set up to each of the build pipelines.
This is part of the Master Build:
trigger:
batch: false
branches:
include:
- master
And this is part of the Pull Request Build:
trigger: none
pr:
- master
We have Release pipelines for each of the Source builds, having Pull Request triggers enabled in one of them only, but you can have only one for your master artifacts, so PRs won't be published.
Say you have a build and its corresponding release definition on Azure Devops.
Generally, the way it's used is like:
Repository "A" changes -> Build repo "A" -> Release to a given environment
Within this scenario (using only one build artifact), it's easy to trigger deployments (after successful build) for different branches.
But, say you also have a release definition with multiple build artifacts (from different repos), and you want to, changes coming from branch "dev" you want to deploy to environment "Development", but if changes come from branch "hotfix" you want to deploy to environment "Staging".
Something like this
You can play with branch filters on the specific environment and artifact filters on the artifact triggers.
The above scenario works very well for "dev" changes when you define your build artifacts to use "dev" as default branch.
But if you make changes on Repo A (branch hotfix), but not in Repo B, the build artifacts for that release will come from different branches, hence the "artifacts will not meet requirements", cause all changes must come from hotfix branch in order to trigger the deployment.
In my opinion, the "Default Version" of the Build Artifact itself, makes this confusion for the pipeline.
See this image example
That being said, how can we trigger a deployment into "Staging" environment if only one of the triggered changes come from the branch "hotfix" ?
The way I can see, when that happens, "Staging" environment never "meets the artifacts requirements", cause other artifacts will use version from "dev" as it's the default source branch.
Has anyone worked with a similar scenario ?
Thanks for reading my question.
Update:
According to your scenario, the best solution at present is to create two release pipelines to deploy separately, because Artifact A and Artifact B have no dependencies.
In the Continuous deployment trigger of the build artifact, you can set Build branch filters to include the dev and hotfix branches.
Then enable Artifact filters in the Pre-deployment conditions of the stage to set the build branch artifact conditions that trigger the deployment.
Artifact filters: Select artifact condition(s) to trigger a new deployment. A release will be deployed to this stage only if all artifact conditions match.
I'd can't seem to find any documentation of manual staging in Gitlab CI in version 8.9. How do I do a manual stage such as "Deploy to Test"?
I'd like Gitlab CI to deploy a successful RPM to dev, and then once I've reviewed it, push to Test, and from there generate a release. Is this possible with Gitlab CI currently?
You can set tasks to be manual by using when: manual in the job (documentation).
So for example, if you want to want the deployment to happen at every push but give the option to manually tear down the infrastructure, this is how you would do it:
stages:
- deploy
- destroy
deploy:
stage: deploy
script:
- [STEPS TO DEPLOY]
destroy:
stage: destroy
script:
- [STEPS TO DESTROY]
when: manual
With the above config, if you go to the GitLab project > Pipelines, you should see a play button next to the last commit. When you click the play button you can see the destroy option.
Update: Manual actions were Introduced in GitLab 8.10. From the manual "Manual actions are a special type of job that are not executed automatically; they need to be explicitly started by a user. Manual actions can be started from pipeline, build, environment, and deployment views. You can execute the same manual action multiple times." An example usage of manual actions is deployment to production. The rest of this answer applies to Gitlab 8.9 and older only.
Historical Answer:
It does not appear as though manual deploy/release was available in Gitlab in 8.9.
One possibility is to have a protected branch which triggers a release. See info about protected branches here: http://doc.gitlab.com/ce/workflow/protected_branches.html
Essentially a protected branch would allow you to Create a branch (testdeploybranch) which only you would be allowed to merge code into. Whenever a commit to dev would pass the Gitlab CI tests and deploy jobs, as well as your manual review, you could merge that commit into the protected branch to trigger the release. For this branch you can then set up a special release job in Gitlab CI using the only option in the .gitlab-ci.yml job definition. Read more here: http://doc.gitlab.com/ci/yaml/README.html
So something like this:
release:
only: testdeploybranch
type: release
script: some command or script invocation to deploy to Test
This might not be exactly what you are after, but it does allow you to do manual releases from Gitlab. It does not provide an easy way to manually do the same release procedure manually for different servers. Perhaps someone else might be able to expand on this strategy.
Finally, we have Gitlab CI manual actions that were introduced in GitLab 8.10.
I have a project in GitLab that is integrated with Gitlab CI. Every push to master shedules a build of the project.
However, when a new branch is created and pushed into repository, build is not sheduled in gitlab CI. What are the settings for enabling build of other branches - alterativaly, how can i figure out what went wrong?
how can i figure out what went wrong?
Analyse .gitlab-ci.yml. Take a look at this, I would take a wild guess that you have limited your job execution with:
...
only:
- master
...