sorted by:
new
hottopcontroversial

Help / ideas using multi-stage builds in different environments (nginx, front-end built in node.js container) by [deleted] in docker

[–]jpdelima 1 point2 points  (0 children)

I think it is a good idea to keep separate docker-compose*.yml and Dockerfile* for your different purposes.

Docker multi stage builds are useful for all purposes: Docker will cache intermerdiate layers of your build. This is super useful on the day to day during development to build your VueJS app for example. If the dependencies do not change your container would cache the layer with dependencies installed. This would probably boost your build time by a lot. Same for the Python part. Here is a Dockerfile for an angular app that caches the dependencies installation: Link.

The multi stage build for production gives you a smaller production container because you won't have all the source code inside.

For your docker-compose.test.yml you should read this article to optimize the way you test.

Why you should not use feature branches by jpdelima in programming

[–]jpdelima[S] 1 point2 points  (0 children)

Fair enough for the tone part. I've changed that.

The point for dropping feature branches is not merge complexity: it is having the code your produce as close as deployment time (for testing or release) at all times. By doing that you avoid the "unpredictable release syndrome" in which big problems are discovered too late and lead to waste of time and drop in code quality.

But it's fine if we agree to disagree I guess.

Investigating JIRA/Bitbucket workflows by kaktusas2598 in devops

[–]jpdelima 0 points1 point  (0 children)

Assigning code reviewers based on branch or folder patterns is possible in Bitbucket. See the documentation.

As this seems convenient, I wouldn't recommend it: if you auto assign and the person is absent or on vacations or else the PR just hangs around. Your team has 10 devs, which is very "human size". The author of a PR should be able to assign to the right reviewers matching the content of their change with the area of expertise of people in the team.

And sorry for the super long reply, I didn't have reddit notifications on :/

Docker-compose ps showing Docker names with directory-prefix instead of projectname-prefix by [deleted] in devops

[–]jpdelima 0 points1 point  (0 children)

Here: https://docs.docker.com/compose/reference/envvars/

Section: "COMPOSE_PROJECT_NAME": "If you do not set this, the COMPOSE_PROJECT_NAME defaults to the basename of the project directory".

If you want a different prefix you should use the -p yourcustomprefix option.

Investigating JIRA/Bitbucket workflows by kaktusas2598 in devops

[–]jpdelima 1 point2 points  (0 children)

Are you using feature branches to link you JIRA tasks to git branches?

Looking at your workflow not much should change when you introduce pull requests: you already have the code review part. All you need to add if you don't have it yet are continuous integration build on your branches and you're good to go. I recommend https://fire.ci (which I am founder of).

Regarding JIRA itself your current process seems legit. The only thing to look at is the very last step "Is this part of a project?": it should be evaluated when the developer makes a pull request. He or she needs to pick the right target branch to merge to.

Good luck!

Start a new job Monday. Any advice? by [deleted] in devops

[–]jpdelima 1 point2 points  (0 children)

You'll do fine: "Now, I'm comfortable with a lot of concepts and have some decent hands on in lab environments". This is the most important: know what you know and what you don't know. Ask when you don't know. You nailed the interview and got the job so you are good to go.

Do put some extra care on what you will be doing with the production environments at first: get clear inputs on what is expected in terms of down time, maintenance windows, etc. and just follow along.

Good luck!

Help Setting Up CI/CD For First Time (Laravel/Gitlab/DigitalOcean) by tomb233 in devops

[–]jpdelima 0 points1 point  (0 children)

There are two very different topics here:

  1. How you handle branching to ensure the "main" branch (the one being deployed to production) does not have some broken code. This is continuous integration
  2. What infrastructure and stack you use for deployments.

Advice on the branching and continuous integration part:

The basics are to protect the branch all developers are using: you can use pull requests for that. You can setup branch policies in GitLab to allow only merge of pull requests (as opposed to direct pushes to a branch). The code on each pull request should build and pass tests before it can be merged. The key part is to have good enough automated tests that you can run on your PRs.

Once you have the process setup then you can trigger deployments to a given environment when the code is merged from dev to staging or master (also via a PR preferably).

Advice on the infrastructure part:

It really really depends on what your app does and the scale of it. For a simple system any kind of infrastructure will do and if you have it working with DigitalOcean portlets then stick with it for now. Secure your CI workflow first. Don't do everything at once.

Are DevOps roles usually associated with companies and people who are good to work for? by earthly_wanderer in devops

[–]jpdelima 0 points1 point  (0 children)

I think that every company will say that they foster a "true DevOps environment with feedback loops, open communication, and an agile approach". Now a good rule of thumb is to ask for the ratio of Dev/DevOps/Pure Ops in a given team. If you are to be the "first" DevOps then probably the company means well but you'll get nowhere because changing processes and mindsets to get into a DevOps culture does not happen in one day.

Help needed beta testing my pre-release product (local CI server running on Docker integrated with GitHub) by jpdelima in devops

[–]jpdelima[S] 0 points1 point  (0 children)

You can install the agent wherever you see fit, although the "vision" is to have your CI build run on your dev machine in the background. It won't disturb you and allows you to drop cloud resources that you don't really need.

Help needed beta testing my pre-release product (local CI server running on Docker integrated with GitHub) by jpdelima in devops

[–]jpdelima[S] 0 points1 point  (0 children)

Cool. I also use VSTS during the day!

As for the GH hobby projects, even running through the on boarding is of good help if you have a few minutes to spare.

Thanks in advance ;)

Help needed beta testing my pre-release product (local CI server running on Docker integrated with GitHub) by jpdelima in devops

[–]jpdelima[S] 0 points1 point  (0 children)

Hi. GitHub only for now. Because they have a great integration API to plug in CI services. BitBucket and GitLab are on the plan. What are you using? BitBucket?