The Atlassian website includes a comparison of different workflow strategies available when concerned with Git. More strategies exist, like the one used by Linux Kernel team, but are not relevant to most organisations.
The workflow types most commonly used are -
Centralized - every change is added using a single branch.
Feature Branch - every change is ...
To identify a constraint in any process is a relatively simple task. Work moves from a person to person throughout the organization and it will simply pile up in front of a constraint. You can look for people or teams with the highest number of blocking unresolved issues for example. It depends on how you track the flow of work, but if you do track it, then ...
The simplest/cleanest branch strategy is IMHO the one used in continuous deployment: a single/main integration branch which is also your release branch. From What is Your Branching Model?:
Commits can go all the way to production from one trunk/master, if the
automated build says the commit was good. It’s the turbo-switch for
TBD, where no ...
Assuming there are no changes in Master that are not in your release branch and you don't rebuild after you merge the code then you could deploy first and then merge to master. If either of those are not true, then merging first would be more common.
The process depends on how you handle your branching strategy. If other things could be merged into ...
Kustomize offers a way to "hint" where to find image tags.
Add a file called kustomconfig.yaml:
- path: spec/workflowSpec/templates/container/image
Add the following to your kustomization.yaml:
You're done. The images transformer will pick up those fields.
Each Git hook is executed when a particular Git command is run. See the Git documentation on hooks for specifics. If you have two pushes updating the same ref, whichever one completes the "update" hook first gets to update the ref, and the other will get an error. It doesn't matter which client started to push first. It's all about which got to update the ...
In general git allows concurrent operations because one of them will eventually fail. Some specific database updates will have file locks (like updating the index files) but multiple receives can be in flight at once I think. In this case whichever verification completed first would be allowed in, and the second would fail due to having an invalid history (i....
You can read book about best practices for git: https://git-scm.com/book/en/v2
Example for some git strategy in project:
Creates branch named like a task, feature/XXX-1
Sending task for review
If not review, fixes and again review
If reviewed go to test
If test not passed, fixed and again review/tests
First time review:
git pull dev
git checkout -b ...
My favourite workflow is the development-less "branch per feature" workflow from Adam Dymitruk (http://dymitruk.com/blog/2012/02/05/branch-per-feature/). It has these branches:
Exactly one master in an unbroken line from day 0 up to the version of your app that is currently in production.
Many feature-... branches.
One (or if you are so inclined more) qa ...
here are my 2 cents,
You can use GITLAB to have merge requests for all your security requests like adding users to the groups for every new user or existing users. the Mr can be approved by only your IAM admin. You can use GITLAB CI pipelines to go and perform the operation once the MR is approved. From the users side, the user has to provide their keys ...
Continuous Deployment is certainly a no brainer for mission critical applications but you may try Azure DevOps from MS which integrates with AWS beautifully and has provisions for environment approvals which can help move to that state in a user friendly and elegant manner. IMO, AWS code deploy is still not at par with Azure DevOps. And perhaps you may want ...
You can specify that you want gitlab to execute your CI job on a windows machine using tags.
Gitlab made Windows Shared Runners available as Beta in Jan 2020. Their announcement shows how to use the tags key in your .gitlab-ci file to specify Windows machines.
You can also run in a docker container in windows:
Welcome to DevOps SE!
Is it possible to make data management and operation of data sets to be an asset on its own? It seems like data has become more important so a more data-centric approach could help.
Program managers have the insider info on what the demo data needs to
This proves also organizational silo and lack of communication in the ...
You have a lot of ways to automatize you infrastructure. For your pipelines you can use a tool for this like Jenkins, Travis CI, GitLab, Concourse CI, Drone IO and through turn better CI/CD for your developer.
From the perspective of automating the infra, you can use Terraform to raise it, manage to maintain the default using Ansible and to handle jobs you ...
Indeed that there can be a compound set of measures to reduce build times.
Consider using RAM volumes for builds to reduce filesystem I/O latency
Consider defining more build targets (Vakilian et al. 2015) and if possible build them in parallel with more hardware build agents
Consider parallel execution if supported by software build agent e.g....
In some cases, depending on the actual configurations being targeted, it might be possible to try the effect of various changes live, using other automation tools, and only update the docker images (which acounts for a big chunk of that waiting time) after the bulk of the config changes are eliminated.
Stabilizing first the common/base docker image used ...