45

A big part of DevOps is making it possible to release very often. That comes with automated build, automated testing, etc. You can say that to achieve its goals, DevOps need to use automation to be efficient. Here's how DevOps and automation are related. DevOps is not just automation, there's more to it. Conversely, automation is not exclusively used by "...


22

Continuous delivery and continuous deployment both take continuous integration one step further, by adding a 'deployment to production' step to the process. The difference between continuous delivery and deployment is that for delivery this step is done manually and for deployment is it automatic. Difference between Continuous Integration, Continuous ...


16

I would keep the ECS container instances (I'm talking about the Docker hosts - I don't like AWS terminology here) and the deployment as two separate things. Get your ECS stack up and running. You can manage it through CloudFormation and Auto-scaling groups, that's fine. Just think of your cluster as a platform where you will deploy to, not something you ...


15

Automation is a key attribute of DevOps, but it's not the full story. The question is kind-of like "What's the difference between time-boxing and Scrum?". You'll hear DevOps called a 'culture', a 'movement', a 'methodology', and all kinds of things that won't box it in well enough for you to understand it, even though those descriptions are accurate. In a ...


13

DevOps is really a cultural shift - it's intended to be about breaking down the traditional barriers between operations and development (and really also with QA and the rest of the business!). The idea is that rather than having departmental 'silos' you can work directly with other teams to get things done quicker and more efficiently. It's all about ...


12

In general, there are five main differences between different CI software solutions. Cost: Is the software open source and free or proprietary? Does your DevOps team already have a budget for software or are you expected to compare free options? Maintenance: Is the software something you need to host on your own and maintain, or is it being offered as a ...


12

Instead of Continuous Integration and Continuous Delivery, I would define the definition of done as "Active Continuous Improvement at all levels of the organisation". The other topics like automated builds, CI/CD, etc... these are just milestones and most definitely not the ultimate goal for the organisation in its DevOps efforts. It does look like it ...


11

Because you mention waterfall, I understand that the numerous branches you are alluding to are feature-branches rather than maintenance-branches. In this setup, I also assume that these branches are created according to a waterfall plan that tries to minimise conflicts. This implies that the goal of the development is to produce several distinct products. ...


11

There are no fundamental technical issues with running multiple jenkins slaves on the same machine. In fact Running Multiple Slaves on the Same Machine lists several good reasons for doing it: While the correct use of executors largely obviates the need for multiple slave instances on the same machine, there are some unique use cases to consider: ...


10

I'll give my experience on this one, mostly because it showcases why some answers are not always applicable. Some context to start: We have 7 environments to host roughly 80 applications, most of them rely on each others through webservices or shared tables on db2-iSeries. For good or bad, the iSeries are our DB system of reference. This last point ...


10

Is there any other viable solution, maybe better than the ones above :) ? For Jenkins probably no, due to the license issues you mentioned (you have to run macOS on Apple branded hardware). If you can work with that then it's definitely a solution. If not, then I'd suggest you to check for a hosted iOS continuous integration system where you don't have to ...


10

GitOps is a technique of using Git to manage infrastructure provisioning and software deployments. This technique uses many of the features of Git such as Pull Requests to manage and trigger deployments, and allows "diffing" (looking at the difference between commits) to view the differences between deployments. DevOps is more of a culture or philosophy. ...


9

You need to write some unit tests and set the script variable in your .travis.yml to actually run a file. By default, Travis CI runs the command phpunit without any arguments. When this happens, phpunit doesn't know what you're asking it to do, and shows a help message, then exits with error code 2 (i.e. non-zero, which indicates an error occurred). The ...


9

I Googled "Push on Green" and the first link was: https://www.usenix.org/conference/lisa14/conference-program/presentation/klein This was representative of almost the entire first page. It looks like this term originated in Google's SRE group and has been taken up by the industry at large. You are correct- "push on green" means that deployments are ...


9

Conceptually, this approach is not the way to go; the build directory is not a deployment directory, it's a temporary directory, to build or to deploy from, whereas on a shell executor this could be fixed. So what you need is to deploy from that directory with a script as per gitlab-ci.yml below, to the correct directory of deployment. stages: - deploy ...


8

A judicious usage of one of the cloud "orchestration" tools, such as Terraform or possibly Fugue seems to be the best way. You can start small, pick a less important and not very extensive environment, carefully decipher it into automatable code and proceed from there. Broadly this is referred to as infrastructure-as-code, for googling and other buzzword-...


8

Sounds like you're talking about a test environment which is constantly re-used without being reliably re-initialized for every test execution. This makes such test an unreliable one. Similar, from the reliability perspective, with manual testing, if you want. IMHO you shouldn't be using such testing inside your CI/CD qualification purposes as that will ...


8

TeamCity : It does look nicer, if this is important for your team then it should definitively weight in. That said, if it is VERY important than you probably will end up creating tools or some sort of dashboard overlay to support your team at which point what you really want is the one with the best API. Have not tried Jenkins API so I cannot compare, ...


8

JFrog Artifactory and JFrog Bintray both manage binaries (and any other file type you can think of). I'd like to see them as two different parts of your CI/CD pipeline. Artifactory is mostly meant to be used inside the organization. For managing all binaries coming in as dependencies (like maven central jars) and being produced by your build process (like ...


8

Personally I don't see any reason for which an Artefact Repository - the recommeneded DevOps tool of managing artefacts - wouldn't be applicable to trained neural nets or other artefacts. The artefact size might have some upper limit for a particular artefact repository, but in such case it would be a technical or policy limitation one, not a fundamental/...


7

The usual approach is to create different environments: DEV - this is the place where dev team mess the things. Here are create all changes tunings, deploy new version and so on. Here is the place where CI is integrated fully. PREPROD/QA - this is the place "play" QA/test/validation team do tests. This environment usually freeze during the tests. ...


7

The output of docker images is really intended for humans, and it's not very parse-friendly. Instead, most Docker commands support a --format flag using Go templates. As you can see in the images documentation, you only really care about the .Size value, so you really want this: docker images --format "{{.Size}}" This just gives an output like this: 90.6 ...


7

Vagrant is for setting up test environments right? Ansible/Chef etc. seem good for servers you own, but what about cloud? Docker... great for standardizing app, so why use Ansible/Chef? Kubernentes.. good for deploying to multiple environments and scaling Just a personal note: the way you formulate these things makes me assume that you are diving freshly ...


7

Sit and watch the pipeline run? No, that is not how you work efficiently. Developers push their commits to the source control repository and then the CI/CD pipeline is triggered. Developers may post a well-written pull request anytime they want. There is usually a visual mark representing an "on-going build"/"failed build"/"successful build". Typically a ...


6

As far as I can tell, you're looking for a tool that will reject commits that break the build—a CI tool probably won't be able to prevent regressions by actually fixing your code, but it can stop you from adding bad code to the repository. Atlassian has a few interesting applications of Git hooks: Server-side pre-receive hooks are an especially powerful ...


6

When migrating from something to something else, there are only two things you need to define: What is your target How to get there (the migration plan) The first part is, sadly, often overlooked or way too vague. You cannot simply say that what you have is a mess and you want to organize it. What would that mean? Everybody would have a different ...


6

The SCM system you use can be essential in making your CI choice. Using a private/intranet solution, for example, pretty much excludes CircleCI and TravisCI as these only support cloud-based GitHub and/or Bitbucket. Jenkins has plugins supporting many SCM systems out there, see Which SCM tools does Jenkins support?. But using a less popular or a wrapped/...


6

On the whole, the user experience is pretty similar. TeamCity has a prettier UI, but isn't particularly easier to use. In terms of functionality, the two are effectively equivalent. Most of the terminology is the same as well. The plugin ecosystems are fairly different, however; you'll definitely want to look at what plugins are available for TeamCity to ...


6

By default Jenkins assumes whether the build is SUCCESS or not from build process exit code. Which means that build exit with code 0 considered as SUCCESS, rest all are considered as FAILURE. If your build step/process exit with code 0, even during the failure case then Jenkins will report the build is SUCCESS. So I my suggestion is to run the all build ...


6

As described in the documentation you are following to install on the first paragraph: You can download a binary for every available version as described in Bleeding Edge - download any other tagged release. Following the link in this sentence allow your to find the tag list page Last version in 1.X (Hence compatible with 8.X versions of Gitlab is 1....


Only top voted, non community-wiki answers of a minimum length are eligible