Hot answers tagged

11

When I raise build size issue as a concern, it usually doesn't come from "it is so big, it will be expensive to store it". The main problems with large builds are the following - increased shipping time. moving big bits from place to place frequently is time consuming. frequent changes to big artifacts plus a large enoug retention period make storing such ...


11

Let's say you take out the master branch (you can rename develop to master to confuse your team if you like later) and simply use tags for releases either on develop or hotfix branches. You took out a branch, but the difference is just a change in syntax. Change for change sake. Now let's say you actually take out develop with keeping the locked master ...


8

What exactly are they? Here is a quote from reproducible-builds.org: Reproducible builds are a set of software development practices that create a verifiable path from human readable source code to the binary code used by computers. Why are they important? IMO the easiest way to explain their importance is to consider them as a variation of a backup ...


8

There is currently no ability to restrict jobs which are able to run on the same agent from potentially interacting with each other. There are a bunch of feature requests asking for this sort of granularity, but if I understand your question correctly the most fitting request would be this one BAM-2504 Jira Ticket It's a huge gap in the product line, the ...


8

Since you've tagged this question as "culture", I'm assuming you're not interested in a specific application, but in the broader questions of workflow and management. I'd probably start with "The DevOps Handbook"; it's a good overview of different things to consider, without diving too deep. "Continuous Delivery" by Jez Humble is also often referenced; I ...


7

TL;DR depends on the use case with up to 12 times between best/worst Comprehensive testing has been done over at Phoronix (28.03.18) and the results are very mixed. The tests looked at: Clear Linux 21510 Debian 9.4 OpenSUSE 42.3 Leap Ubuntu 16.04 LTS Windows 10 Pro Build 16299 Debian 9 On WSL OpenSUSE 42.3 On WSL Ubuntu 16.04 LTS On WSL The results are ...


7

This is not about DevOps, but straight software development, I assume. I want to understand the culture better Well, the big thing in straight development (without the "DevOps" angle) is certainly "agile", i.e. for the most part SCRUM. You might do worse than to sit down and read the Agile Manifesto or a primer on SCRUM, or Kanban for the more day-to-...


6

1) How can I run several different branches on the staging server? Docker 2) How would I set up the DB evolution system to make sure it always has appropriate DB for each branch? This depends on how much you expect your DB to scale. You can get pretty crazy with methods to clone database data but typically you will want a master copy that you do not ...


6

It's not possible to avoid setting the BUILD_NUMBER environment variable, but you can avoid using it. Try using the Jenkins plugin Build Name Setter Plugin. It adds an option in your build configuration to set the build name to whatever you want, and you can ignore the BUILD_NUMBER environment variable this way. Consider 1.250.5 versus 1.250.${BUILD_NUMBER}....


6

IMHO the problems you're facing are just a side effect of the poor branch strategy you started with: you're effectively plowing new development on develop (i.e. what converges towards the future production code) through the current production code on master. This leads to contradicting requirements and problems since typicaly the future code diverges from ...


5

Complementing Evgeny's answer with a few more examples. What you mean by build size may matter a bit: if it is the size of the artifact(s) being built (each one individually or their combined size) - that could matter in artifact storing or use/deployment operations if those operations have size limits and they are exceeded. For example Google App Engine ...


5

You are already building and testing code on each of the pull-request and hot-fix branches. This means that in aggregate, the sum of all branches pending on pull-request are your virtual develop branch. You can create a system when in a test environment, several pull-requests are cherry picked into a temporary branch that is not published to the main ...


4

Well, you can pass multiple goals to maven in command line simply by passing them as arguments. Skipping test require a java system property that you can also pass as an argument to the command line. For packaging a maven artifact, executing a sonar analysis with the maven goal but skipping executing the tests you should use : mvn package sonar:sonar -...


4

To provide a practical example of an attempt at creating a truly repeatable build consider the following - A build pipeline which starts with a git repository for which no user can ever rewrite history or delete unmerged branches. The first "build" step after checking out the source code is to spin up a container which contains all the build time ...


3

There are a few main reasons why you would use Artifactory (or any other binary repository manager) over a traditional file storage (in your case NFS). The ability to manage your artifact versions A central location to access artifacts across infrastructure (which you have accomplished with NFS) The ability to download/recreate previous versions of the ...


3

This pipeline will run each day at 1 AM. It'll restart if the build fails. pipeline { agent any triggers { cron('0 1 * * *') } stages { stage ('Build') { when { expression { // When last build has failed !hudson.model.Result.SUCCESS.equals(currentBuild....


2

Well @dan-cornilescu says it well for your particular problem, but the more general case for Trunk-Based Development (mentioned in the Continuous Delivery, Lean Enterprise, and The DevOps Handbook) is made here: https://trunkbaseddevelopment.com/


2

For a laptop, desktop or standalone server, consider trying out Docker containers. These containers are designed to allow you to provide differing libraries, packages and shared objects uniquely to each application. You can have several different Docker containers running different and even conflicting libraries for the same application. You should be able ...


2

Have you considered setting up a build server (i.e. Jenkins, TeamCity) with disposable build agents? If you do it in the cloud (i.e. via ec2 integration), you can literally set up an AMI with generic dependencies, then configure it to spin up a new VM for each build agent, which can be configured whichever way, and then delete the VM once you've done ...


2

On GitHub - you can't. Basically, their PRs are temporary branches, and there's no check if base commit is HEAD of branch to merge in. This problem is solved with gating systems like Zuul, which puts all PRs into queue to run tests. You are talking about systems for managing and storing code, while the issue is in CI scope (i.e. Gitlab flow has this issue ...


2

I'd argue that this isn't actually about staging servers. A staging server closely mimics the production environment, and is where a release goes immediately prior to going to production. A feature branch that hasn't been merged into master is not going to be released directly to production, so it should not go on a staging server. If we reframe the ...


2

In my field (science) Anaconda is probably the most common Python distribution in use. conda is the package manager (just to be clear of the distinction). It is difficult to find fault in conda when compared with pip+virtualenv. The one point that I would make is that the Anaconda distribution is meant to be installed per user. If you have a Python ...


2

Docker is going to be far more well-known than Mock. I consistently see Docker used during build in companies that I work for. I think I have seen Mock before, but only because I am a Fedora user. However, Docker is not a build tool in of itself, so you can still use Mock inside a container. This is a great way to avoid the "snowflake" build server. By ...


2

In many cases compilers are used as-is, already packaged by 3rd parties. When changing the structure of the build systems changing compilers usually translates into switching to a different version, but which is also pre-packaged. If this is your use case the artifact repository offers a single advantage: availability. Even if the provider decides (for ...


2

You are running into a conflict between jenkins nature of making sure everything is done before a job is complete and your desire for some long-running things to be asynchronous. There is no right answer here, both are reasonable desires, but you and jenkins are pulling in different directions. It may be ok for some parts of the jenkins job to not be ...


2

I'll add a very concrete issue that we actually run into. It's a sideeffect of bad architecture that we're suffering currently: Since our build is large and we need to load a lot of dependencies simply putting it all together takes a very long time. We should have long since divided the build up into numerous small builds as an approach to a microservice ...


2

You need something that will do basically CI/CD. There are few options (in no particular order): Gitlab + autodeploy (or custom deployment) skaffold + git-sync + kaniko There are more, but basically, you need a component to watch for changes, something that knows how to build an image, and something else that can deploy it (some of these might be done by ...


2

First of all, a job should always be green on the first run in my opinion. I know that it can be very difficult, but every issue should be solved. That having said, we have also some jobs that get green after 5 retries. It are selenium tests that are very brittle and we do not get the time to fix them. Once a retry was added the builds are green for a couple ...


1

In your deployment project configuration for each environment you could add a task prior to the actual deployment which would take care of setting up the right configuration file. It could be a script simply copying/replacing the configuration file just as you currently do manually. The script could be invoked with some pre-configured argument to identify ...


1

As per this docker documentation the copy instruction may have multiple sources but only one destination. Your first copy is coping two file /etc/passwd and /etc/group to /etc.


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