What is the MMM
First I want to explain the context for Brook's Law. What was the assumption that made him create it back in 1975?
A Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks' law says that it is impossible to measure useful work in man-months.
It is a common misbelief that “DevOps” is a role in a company. The word merely denotes an organisational shift in software companies, this shift can be shortly described by the “You build it, you run it!” coined by Werner Vogels:
There is no need to distinguish between building and running, and according to Werner Vogels, it is much better than that:
As you guessed, build not necessarily means "compile". Building is a process of creating software from sources, which might include stuff like gathering dependencies, compiling, archiving, transforming code in any way, but also testing, deploying to different environments and promoting the artifacts between them.
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 ...
So what you have actually is this:
As your API ELB is in a private zone it can't be accessed from the internet.
Your frontend in React.js just run in User's browser and not on the UI servers, those server just serve static files.
You have two options, configure your frontend servers to redirect API calls to the API ELB or just update the API ELB to be ...
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-...
At the risk of getting vote down, off-topic or even heresy, I going to tell you,
"Don't listen to the purists telling you that DevOps is not a role."
You are on the right track. It should fit your company. That's what matters when hiring.
If you need a DevOps, to work like a DevOps, produce results like DevOps, it is a DevOps.
Don't let anyone dissuade ...
"Hiring a DevOps" will be tough because DevOps isn't a role. IF you can find an engineer with software development and engineering skills, you're on the right track..
Your hiring process will be complicated by a few factors:
Site Reliability Engineers (Google's term for admin/engineers with coding skills) are rare
Rare skills are expensive
What I have done (and this is only subjective) is as follows:
When a manager thinking about a due date wishes to add people into my team to cut the time needed and seems under MMM, I first discuss with him or her on why this could be bad. My favorite analogy for this is to remind them that if one woman can have a baby in nine months, nine women won't have ...
Speaking exclusively from a CI perspective, increasing the number of developers working on a project typically translates into more people working in the same branch.
Traditional CI systems have a scalability issue in this respect: the probability of breakages/regressions/blockages increases slowing down the integration speed and inviting smaller teams to ...
Yes. Although DevOps is a culture and not a role, one should assess the mindset and technical skills of a candidate.
At my previous work we conducted two interviews. The first one was a conversation about the mindset. If my colleague and I were positive then we offered the candidate the possibility to prepare a demo for the second interview. He or she could ...
Yes, there absolutely should be an assessment, however it would be a good idea to agree upfront with one of the few DevOps people you know to validate the content and results.
Regarding the contents of the assessment, there are some questions still remaining after your edits. Key one is how your operations are done. Possible options are: you already have ...
I look for a number of things in the people I have hired into this space.
a minimum of 'ha' level of agile (google shu, ha, ri for agile adoption if you need more)
technical hands-on experience - coding, automation, etc, but I'm tool and language agnostic
learning personality - they take the initiative to constantly learn
inquisitive and not looking to ...
There are two possibilities:
You need help figuring out what are the changes your company needs to go through on your journey to DevOps.
You know what you need and just look to hire people to implement this vision for you.
If you need someone to help you figure out which issues you need to concentrate on, there is a really good company called DORA (...
One of the major advantage of the container technology is standardisation: easily replicating the same environment wherever a specific container is used, be it, for example, on your own machine during development or on the CI machine during the execution of the CI/CD pipeline.
Building and using custom containers is a pretty standard way of including OS-...
For all of your read-only dashboard needs, there is Grafana with multitude of plugins, data sources and visualizations (tables, charts etc). You can also program your custom data sources pretty easily with official "simple-json-datasource" plugin.
By default, Grafana does not support buttons or other kind of form/action stuff on its own. Grafana is all ...
According to Wikipedia
Manufacturing is the production of merchandise for use or sale using
labour and machines, tools, chemical and biological processing, or
a project is an individual or collaborative enterprise, possibly
involving research or design, that is carefully planned, usually by a
project team, to achieve a ...
Agile fits very well with a DevOps culture and pair programming is no exception.
The following are some examples of "pair programming" principles applied in a DevOps context:
A pair of individuals working together on a Dockerfile for their service.
A pairing sits together to work on defining their infrastructure as code.
A traditional developer and an IT ...
Because you have a large project with multiple teams using multiple development branches will give you merge headaches, especially if the core and extended features have a significant overlap in the codebase.
The extended feature team(s) will spend a lot of time periodically merging the core feature changes and dealing with the fallout from each such merge,...
You could use Jenkins along with Gitlab for your CI. Both are free. As far as the Qt project goes, you could use the sh or bat steps to run qmake, or cmake for that matter, from within the build job.
There are also a lot of plugins to extend Jenkins and integrate it with Gitlab. This includes plugins that allow you to trigger builds when pushing to a ...
This sounds like an asymmetric or n-path routing issue. Here is what is probably happening:
Machine A at IP address 192.168.1.1 makes initiates a [SYN] request through the LB at 192.168.1.10. the LB then proxies the payload to Machine B at 192.168.1.2, so the payload now has source: 192.168.1.1 and has has destination: 192.168.1.2 (which used to be 192.168....
Aside other questions I believe the following answer is yet missing - I want to summarize what I have learned so far in a mostly humble tone:
Introducing DevOps skills to your team is probably not enough (that is to consider that you cannot hire a DevOps)! (Like asking on a lower level what are best tools to make things work, here you seem to want your ...